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HITACHI:    PIONEERING  A  "FACTORY"  STRATEGY  AND  STRUCTURE 
FOR   LARGE-SCALE  SOFTWARE  DEVELOPMENT 


INTRODUCTION 

This  paper  is  part  of  a  larger  study  examining  the  question  of  whether 
or  not  companies  are  choosing  to  manage  a  complex  engineering  activity 
such  as  large-scale  software  development  with  a  range  of  strategic 
considerations  and  organizational  as  well  as  technological  approaches  that 
corresponds  to  the  spectrum  usually  associated  with  "hard"  manufacturing, 
i.e.  job  shops,  batch  organizations,  and  factories  exhibiting  various  degrees 
of  flexibility  in  product  mixes  and  technologies.  The  research  project 
includes  the  proposal  of  technology  and  policy  criteria  defining  what  a 
factory  environment  for  software  might  look  like;  a  survey  of  38  software 
facilities  in  the  U.S.  and  Japan  to  determine  where  firms  stand  in  relation  to 
these  criteria;  and  detailed  case  studies  examining  the  technology  and  policy 
implementation  process  followed  at  firms  identified  as  being  close  to  the 
factory  model .  ' 

There  are  several  interrelated  conclusions:  (1)  This  spectrum,  including 
"factory"  approaches,  is  clearly  observable  in  the  sample  of  software 
facilities  in  the  U.S.  and  Japan.  (2)  There  appears  to  be  nothing  inherent  in 
software  as  a  technology  that  prevents  some  firms  from  creating  strategies 
and  organizational  structures  to  manage  product  and  process  development 
more  effectively,  even  with  a  relatively  new  and  complex  technology  such  as 
software.      (3)    The  basic  technological   infrastructures  to  aid   software  process 


management  are  not  significantly  different  between  Japanese  and  U.S.  firms. 
(4)  But,  Japanese  firms  --  led  by  the  NEC  group  and  Toshiba,  and  followed 
by  Hitachi  and  Fujitsu  --  are  significantly  ahead  of  most  US.  competitors  in 
implementing  "flexible  factory"  type  of  strategies  focused  on  reusing 
standardized  comp^onents  (modules  of  code)  and  then  customizing  end 
products  . 

This  paper  analyzes  what  is  probably  the  most  difficult  aspect  of  the 
software  factory  --  the  implementation  process.  Hitachi  is  significant  for 
two  reasons:  One,  its  Software  Works  (originally  a  facility  performing  both 
systems  and  applications  programming)  was  the  first  software  factory 
established  in  the  world,  and  Hitachi  has  made  available  extensive  historical 
and  technical  documentation  for  this  facility's  technological  and  policy 
systems.  Two,  Hitachi  has  extended  its  factory  approach  to  both 
applications   and   systems   software  development. 


I.    HITACHI:      THE   STRATEGIC  AND  STRUCTURAL  SETTING 
Corpo rate  Organization   and   Products 

Hitachi  originated  in  1908  as  the  machinery  repair  section  of  a  mining 
company  in  the  town  of  Hitachi,  Japan,  a  couple  hours  by  train  north  of 
Tokyo.  In  1986  it  had  approximately  80,000  employees  and  sales  in  the 
neighborhood  of  $20  billion  dollars.  Hitachi  s  major  area  of  business  was 
communications  and  electronics  equipment,  including  computers  and  software 
(36%  of  fiscal  1985  sales),  although  the  company  also  sold  heavy  machinery 
(21%),  home  appliances  (24%),  industrial  machinery  (9%),  and  telephone 
exchange    equipment    and    other    products     (10%).  In    computer    sales    among 


Japanese  companies  during  1985,  Hitachi  ranked  fourth,  behind  Fujitsu,  IBM 
Japan,  and  NEC,  but  was  traditionally  the  market  leader  in  large  mainframes 
and   second  to   IBM   in   very-large  mainframes. 

For  most  of  its  history,  Hitachi's  organization  has  centered  around 
factories,  of  which  the  company  operated  28  domestically  in  1986.  These 
belonged  to  7  groups:  Computers,  Electronic  Devices,  Consumer  Products, 
Industrial  Components  and  Equipment,  Industrial  Processes,  Power  Generation 
and  Transmission,  and  International  Operations.  Group  headquarters  retained 
responsibility  for  sales,  but  factories  have  been  responsible  for  product 
engineering  and  manufacturing.  Factories  also  operate  as  independent  profit 
centers,  with  financial  management  based  on  6-month  budgets  for  each 
factory.  Plant  managers  are  thus  responsible  for  engineering  and  production 
costs,  the  setting  of  production  amounts,  and  any  related  expenses;  and 
company  policy  has  required  factory  managers  to  institute  standardized 
controls  and  procedures  for  budgets  as  well  as  engineering  and  manufacturing 
management.  There  have  been  no  exceptions,  not  even  in  the  case  of 
software.  This     is    what    led    to    the    birth    of    the    world's    first    software 

factory. 

The  Computer  Group 

Computer  exports  for  Hitachi  have  been  relatively  small  in  comparison 
to  domestic  sales  (about  17%  in  1985).^  Mainframes  are  designed  to  compete 
specifically  with  IBM  models  as  well  as  to  be  fully  compatible,  and  appeared 
to  be  of  unique  designs.  For  example,  the  AS/9000,  introduced  around  1982 
to  compete  with  IBM's  3081  model,  used  denser  circuitry  and  a  shorter  data- 
flow   path    than    IBM    to    provide    considerably    more    computing    power    for    the 


dollar  It  v\as  also,  according  to  Datamation,  "a  more  expandable  and  more 
cost-effective  mainframe,  with  expanded  performance  levels  when  compared 
to    a    similar    IBM    system. "°  Hitachi    computers    introduced    to    compete    with 

IBM  s  new  3090  Sierra  series,  the  AS/XL  60  and  80,  also  achieved  computing 
speeds  equivalent  to  the  IBM  machines  with  half  the  number  of  processors 
and   at   a    lower   price. 

The  19S2  incident  in  which  Hitachi  engineers  were  caught  by  the  FBI 
attempting  to  buy  information  on  the  3081  operating  system,  particularly  new 
features  that  IBM  had  decided  to  imbed  in  microcode  ("firmware),  suggests 
that  Hitachi  has  actively  sought  information  on  IBM  machines  and  software 
to  help  its  hardware  and  software  engineers  design  compatible  products. ° 
This  process  of  information  gathering  or  even  "reverse  engineering"  may 
have  also  aided  the  performance  of   Hitachi   mainframes   and   software. 

It  is  also  the  case,  however,  that  underlying  Hitachis  apparent 
technical  success  in  hardware  and  software  is  a  long  history  of  computer 
development,  Hitachi  engineers  began  experimenting  with  this  technology  in 
the  mid-1950s  and  completed  their  first  model  in  1957,  using  parametrons  (a 
solid-state  device  used  primarily  in  Japan  during  the  1950s),  and  then  a 
transistorized  business  computer  in  1959.  The  model  for  this  machine  was 
developed  at  a  Ministry  of  International  Trade  and  Industry  research 
institute,  the  Electrotechnical  Laboratory  (ETL),  and  largely  completed  during 
1956  --  two  years  before  the  commercial  introduction  of  transistorized 
computers  in  the  United  States.  The  main  ETL  designer,  TaUahashi  Sigeru, 
helped  transfer  this  technology  to  Hitachi  and  moved  to  the  company 
formally  in  1962,  where  he  headed  hardware  product  development  until  1980.^ 
Along   with    in-house   research   and   product  development,    Hitachi   also  benefited 


from  a  licensing  agreement  with  RCA  between  1961  and  1970,  tlnrougln  which 
it  manufactured  RCA-designed  computers,  as  well  as  sold  RCA  software,  for 
resale  under  the  Hitachi   label    in  Japan. 

The  production  of  computer  products  before  1961,  along  with  the 
arrangement  with  RCA,  reflected  a  dual  strategy  within  Hitachi:  independent 
development  of  new  technology  as  well  as  direct  purchasing  of  technology 
from  abroad.  This  two-fold  approach  turned  out  to  be  extremely  important: 
When  RCA  failed  to  introduce  competitive  new  products  in  the  late  1960s 
and  then  withdrew  from  computers  in  1970,  Hitachi  had  sufficient  internal 
expertise  to  design  machines  that  would  eventually  compete  with  the  IBM 
370  and  subsequent  mainframes.  Equally  important,  Hitachi  engineers  had  an 
opportunity  to  cultivate  independent  skills  and  develop  a  distinctive,  factory- 
centered   approach   to  software  development.'^ 

Hitachi's  computer  group  in  the  mid-1980s  consisted  of  six  main 
facilities,  two  for  software  and  four  for  hardware.  The  Software  Works, 
which  started  with  348  employees  in  1969,  grew  to  nearly  3000  before  being 
separated  into  two  sites  during  1985.  It  has  continued  to  produce  operating 
systems  for  mainframes,  mini-computers,  and  office  computers;  related 
systems  software  (such  as  language  processors);  and  on-line  data-base 
programs.  The  smallest  programs  were  several  thousand  lines  of  code  and  the 
largest   several    hundred   thousand.  Omori    Software  Works   produces    large- 

scale  customized  applications  programs  such  as  real-time  banking  or  factory 
control  software.  Research  and  development  on  new  hardware  technologies 
as  well  as  software  development  tools  and  design  concepts  took  place  in  two 
corporate  facilities .  ^^  In  addition,  Hitachi  had  numerous  subsidiaries 
producing    computer-related    products     and    services,     including    23    software 


companies 
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HITACHI    COMPUTER   GROUP.    CA.    1986 
EMPLOYEES         PRODUCTS 

2,800 


LLNE    FACILITY 

Hardware 
Kanagavsa  Works 

Odawara   Works  2,400 

Asahi  Works  1,100 

Device   Development  80 

Center 

Software 
Software  Works  1,400 

Omori   Software  Works  1,500 


Mainframe  Computers 
Peripherals 

Smail-Scale  Computers 
Semiconductor   Devices 

Systems    Software 
Applications   Software 


C O R P O RATE    RDD 

Central    Research    Labs  1,200 

Systems    Development  350 

Laboratory 


Basic    Research 

Systems   and   Applications 
Software  Technology 


Corporate   Programs  for  Engineering  and  Manufacturing    Improvement 

The  software  factories  took  part  in  all  company-wide  efforts  at 
analyzing  and  improving  various  aspects  of  engineering  and  manufacturing 
operations.  Several  corporate  programs  appear  to  have  led  to  an  increasing 
refinement  and  improvement  of  the  factory  concept  (technology  and 
procedures)    for   software,    and   of   engineering   performance   in   this   area. 

For  example,  a  company-wide  movement  among  Hitachi  factories  since 
1968  has  been  the  "Management  Improvement"  (Ml)  program.  The  major 
focus  of  this  has  been  to  promote  the  establishment  and  implementation  of 
specific     standardization,      "zero     defect,"     and     p  roductivity- improvement 


objectives.  ^  At  the  Software  Works,  during  1969-1971,  this  movement  took 
the  form  of  setting  standards  for  design,  programming,  and  testing  activities, 
introducing  a  document  control  system  and  a  zero-defect  program,  and 
launching  a  study  of  how  to  reduce  personnel  costs  and  increase  programmer 
performance.  As  a  next  step,  in  1973  managers  asked  all  planning  personnel 
to  submit  suggestions  on  how  to  improve  productivity;  this  resulted  in  1437 
proposals,  some  of  which  were  adopted  quickly  --  such  as  structured 
programming  techniques   and   better  debugging  methods. 

Also  under  the  Management  Improvement  program,  during  the  later 
1970s,  the  Software  Works  launched  studies  of  design  productivity,  reliability, 
profit  generation,  and  market  share.  "*  Management  formally  organized  these 
efforts  through  the  factory  staff  structure,  such  as  a  Rationalization 
Promotion  Center  in  1975  (headed  by  the  factory  manager).'"  The  company- 
wide  focus  in  recent  years  has  centered  on  three  specific  areas  and  potential 
ways  to  integrate  and  improve  productivity  in  product  engineering  and 
production;  Hitachi  has  equally  applied  the  concepts  and  recommendations  in 
hardware  and   software  facilities: 


Area  Main  Objective  Solutions 

Design   technology  Shorter  times  CAD 

Standardization 

Production   engineering  Labor   reduction  Automation 

Process   improvement 

Control   technology  Less  work-in-process  Inventory  control 


Another  example  is  quality  assurance.  Since  the  founding  of  the 
company,  Hitachi  has  followed  a  practice  called  "gleaning,"  which  involves 
picking    out    product-    or    system-design     errors,     analyzing    them,     and    then 


formally  recommending  solutions  and  making  reports  to  colleagues  Factories 
have  case  reports  once  a  month;  there  are  also  reports  at  the  division  level 
approximately  once  every  other  month.  The  Software  Works  adopted  this 
practice  in  1977,  with  the  particular  objective  of  developing  design  and 
analysis  procedures  that  would  reduce  the  recurrence  of  system  problems 
identified  by  customers,  such  as  not  meeting  user  specifications  or  designing 
programs   that   were   not   "user   friendly."'" 


IL SOFTWARE  STR ATEGY:   THE  FACTORY  MODEL 

Product   Proliferation  and   Proqra mmer  Shortages 

The  first  Hitachi  computers  of  the  late  1950s  and  early  1960s  used 
drums  for  main  memory,  and  paper  tape  for  entering  programs  and  data  as 
well  as  receiving  output.  Thus,  they  did  not  require  software  except  for 
simple  input/output  programs  and  a  few  subroutines  for  scientific 
calculations.  With  the  inclusion  of  core  memory  and  card  readers  during 
1963-1965,  it  became  possible  to  use  higher-level  languages  such  as 
FORTRAN  and  to  write  more  sophisticated  programs.  Yet  the  hardware  still 
had  no  interrupt  features,  so  control  programs  were  small.  The  first  program 
resembling  a  modern  operating  system  for  a  Hitachi  computer  was  a  Fortran 
"monitor"'  system  introduced  with  the  HITAC  4010  in  1965.'^  But  this  was 
actually  an  RCA  product  (model  401),  which  Hitachi  produced  from  imported 
knock-down  kits;  Hitachi  required  little  product  engineering  or  software 
knowledge,    except  to  be  able  to  service  the  machine. ■^^ 

An  in-house  project,  on  the  other  hand,  provided  Hitachi  engineers  with 
extensive    experience    in    both    hardware    and    software    development,    as    well    as 
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began  to  strain  engineering  resources.  in  the  early  19GOs,  Hitachi's  Central 
Research  Laboratory  took  on  contracts  with  Tokyo  University,  the  Japanese 
Meteorological  Agency,  and  Nippon  Telegraph  and  Telephone's  main 
laboratory  to  build  a  very-large  scale  computer  capable  of  time  sharing, 
dubbed  the  HITAC  5020.  The  Central  Laboratory  completed  one  unit  for  its 
own  use  in  1964  and  then,  under  the  direction  of  Shimada  Shozo,  set  out  to 
produce  an  operating  ("monitor")  system  that  would  allow  the  5020  to 
perform  input,  output,  and  computation  functions  simultaneously.  Laboratory 
engineers  had  previous  experience  developing  an  assembler  and  FORTRAN 
compiler  for  Hitachi's  parametron  computers;  between  20  and  30  were 
assigned  to  work  on  software  for  the  5020.  The  Central  Laboratory  was  one 
of  two  sources  of  computer  expertise  in  Hitachi  at  the  time;  the  other  was 
the  Totsuka  Works,  which  produced  telecommunications  equipment  and  had 
led  the  company's   entrance  into  computers   during   the   1950s. ^' 

Shimada's  major  source  of  ideas  for  the  operating  system  software  was 
MIT,  where  he  and  several  other  Hitachi  engineers  visited  in  1965  on  the 
introduction  of  a  Tokyo  University  professor  to  the  head  of  MIT's  electrical 
engineering  department.  MIT  researchers  were  then  developing  their  own 
time-sharing  system,  Multics,  using  a  GE  mainframe.  Shimada  received  a  copy 
of  the  manual,  which  discussed  several  new  approaches  and  ideas  such  as  2- 
level  addresses  and  virtual  memory.  In  Shimada's  words,  the  Multics  manual 
"actually  made  our  mouths  water."  As  soon  as  he  returned  to  the  Central 
Research  Laboratory,  he  made  the  development  of  a  comparable  operating 
system  his  next  project,  in  cooperation  with  Tokyo  University's  Computing 
Center.  The  first  delivery  of  the  5020  was  in  1965,  to  Tokyo  University . '^■^ 
They    finished    a    Japanese    version    of    Multics    in    1968,    a    couple   years    before 


The  5020  was  not  suited  for  businesses  and  the  project  team  became 
short-handed  as  Hitachi  management  gave  priority  to  developing  system 
software  for  the  HITAC  8000  series. ^4  Introduced  during  1967-1969,  the 
8000  family  was  a  Japanese  version  of  the  RCA  Spectra  series  (which  v,ss 
partially  compatible  with  the  IBM  360).  The  8000  also  provided  a  major 
incentive  to  create  a  formal  strategy  and  mechanism  for  program 
development,  because  RCA  was  not  developing  adequate  system  software. 
Hitachi  decided  at  first  to  use  the  RCA  operating  system,  TDOS,  but  this 
required  at  least  two  magnetic-tape  stations  for  compilers  and  the  program 
library.  in  contrast,  a  major  feature  of  the  IBM  360  was  that  all  functions 
were  available  on  a  faster  and  larger  disc  drive  system.  While  RCA 
hesitated  over  whether  or  not  to  develop  a  disc  system,  Japanese  customers 
insisted  on  this,  prompting  Hitachi  to  start  modifying  RCA's  TDOS  around 
1966  and   create   a   new   "disc  operating   system,"    DOS.^^ 

Designing  an  effective  disc  operating  system  capable  of  on-line 
processing  exacerbated  the  strain  on  software-engineering  resources  in 
Hitachi.  The  manager  of  the  project,  Sakata  Kazuyuki,  found  80  engineers 
to  work  on  the  system,  with  assistance  from  Hitachi  s  Central  Research 
Laboratory,  the  Totsuka  Works,  two  subsidiaries  (Hitachi  Electronics  Service 
and  Hitachi  Electronics  Engineering),  and  a  subcontractor,  Yoshizawa 
Business  Machines.  (The  groups  from  Hitachi  Electronics  Engineering  and 
Yoshizawa  remained  together  and  formed  the  basis  of  the  company's  largest 
software  subsidiary,  Hitachi  Software  Engineering,  established  in  1969.) 
Both  TDOS  and  DOS  provided  the  basic  structure  of  EDOS,  which  allowed 
for     greater     volume     on-line     and     large-scale     batch     processing     and     was 
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completed  in  1969;  this  became  the  foundation  for  Hitachi's  current  operating 
system  for   large-scale  computers. 

Yet  another  software  project  Hitachi  tackled  in  the  1960s  was  an 
operating  system  for  a  project  sponsored  by  MITI  and  Nippon  Telegraph  and 
Telephone  (NT&T)  to  build  a  very-large  scale  computer,  called  the  HITAC 
8700/8800  within  Hitachi  (the  NT&T  version,  the  8800,  was  to  be  used  for 
telecommunications  data  processing).  Development  work  for  the  software 
started  in  1968  at  the  Kanagawa  Works  and  was  then  taken  over  by  the 
Software  Works  in  1969.  The  commercial  operating  system  that  resulted  from 
this  project,  0S7,  had  multi-processor,  multi-virtual  memory  capabilities,  as 
well  as  supported  large-scale  batch  processing,  time  sharing,  and  on-line 
real-time  computing. ^°  The  first  commercial  deliveries  came  in  1972-1973, 
primarily  to  universities  and  research  institutes.'^"  The  computer  fell  short 
of  several  performance  goals  and  was  not  as  powerful  as  the  370  series, 
which  IBM  introduced  while  the  8700/8800  was  in  development.  Nonetheless, 
the  project  provided  Hitachi  with  extensive  experience  in  IBM-compatible 
hardware  design,  integrated-circuit  logic  chips,  and  large-scale  software 
engineering.  Furthermore,  the  8700  successfully  targeted  a  relatively  large 
domestic  market  for  IBM-compatible  machines,  which  Hitachi  was  later  able 
to  switch  to  its  M-series,  which  competed  directly  against  the  IBM-370  and 
subsequent   series. ^^ 

Systems  programs  were  not  the  only  software  orders  to  Hitachi  during 
this  period.  Since  few  companies  in  Japan  outside  of  the  computer 
manufacturers  had  in-house  software  expertise,  Hitachi  and  the  other 
mainframe  producers  had  to  design  several  large  applications  programs.  In 
Hitachi's    case,    these    included    a    series    of    real-time    reservations    systems    for 
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the  Japan  National  Railways  (the  first  programmable  system  Hitachi  delivered 
in  1964,  with  1100  terminals  throughout  Japan);  on-line  currency-exchange 
and  deposit  systems  for  the  Tokai  Bank  (1965)  and  Sanwa  Bank  (1967),  and 
real-time  production  control  systems  for  Toyo  Kogyo  (Mazda)  and  Nissan 
(1968). 31 

The  banking  systems  were  particularly  important,  because  most  Japanese 
banks  at  the  time  were  buying  these  from  IBM;  Hitachi's  system  miarked  the 
beginning  of  a  shift  to  more  domestic  systems.  '  Developing  the  Tokai 
software,  which  connected  200  remote  terminals  around  Japan  to  a  central 
processing  center  in  Nagoya,  was  a  particularly  difficult  but  valuable  learning 
experience,  according  to  Sakata.  Before  taking  on  the  job,  he  and  other 
Hitachi  engineers  spent  nearly  two  months  in  the  U.S.  during  1963-1954  to 
observe  several  American  airline  and  banking  systems,  including  Howard 
Savings  in  New  Jersey  and  Continental  Illinois  in  Chicago.  They  were 
thoroughly  dismayed  at  how  difficult  the  programming  looked  and,  once  they 
completed  the  initial  Tokai  system,  it  took  a  full  year  to  get  the  software 
working  properly.  Due  to  the  contract  terms,  Hitachi  was  not  paid  for  this 
extra  debugging  time  and  had  to  absorb  the  costs  itself."^  The  cost  and 
frustrations  of  this  project  made  Sakata  and  other  managers  particularly 
concerned  about  improving  their  ability  to  control  schedules  and  time 
estimates,    as   well   as   bugs. 

Evolution  of  the  Factory  Strategy 

During  the  late  1950s,  engineers  at  Hitachi's  Totsuka  Works,  including 
Sakata,  believed  that,  since  computers  relied  on  digital  technology  similar  to 
the    telephone    exchange    equipment    they    were    already    manufacturing,    Hitachi 
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would  be  able  to  manufacture  computers  independently.  ^  This  factory  thus 
began  hardware  design  in  Hitachi,  and  also  established  the  first  group 
officially  responsible  for  software  development  (mainly  language  processors 
and  utility  programs),  the  engineering  service  section.  The  section  started 
in  1960  with  about  10  engineers  and  in  1963  was  divided  into  two  planning 
sections,  one  for  government  and  university  business,  and  another  for  private 
contracts.  The  concept  of  "service"  was  intimately  linked  to  software  since, 
to  sell  computers,  Hitachi  had  to  learn  from  potential  customers  what  their 
needs  were  and  then  be  able  to  provide  adequate  programs.  Closely  related 
to  this  section  was  another  group  which  trained  technicians  for 
maintenance. 

Hitachi  management  next  decided  to  establish  a  separate  computer 
division  in  1962  along  with  a  new  factory  to  manufacture  hardware,  the 
Kanagawa  Works  (separated  from  the  Totsuka  Works).  The  hardware  design 
section  in  the  new  plant  took  charge  of  writing  or  revising  software  for  the 
new  RCA  machines  Hitachi  was  planning  to  offer.  But  managers  worried 
that  the  dispersion  of  a  scarce  resource  --  software  engineers  --  would 
make  it  difficult  to  write  software  for  the  new  8000  series.  This  situation 
then  led  to  the  creation  of  centralized  system  program  department  in  the 
Kanagawa  plant,  headed  by  Sakata  and  modeled  after  a  similar  department  in 
RCA."^  The  new  department  formally  brought  together  the  group  in  the 
Central  Research  Laboratory  that  had  been  developing  software  for  the  5020; 
the  software  engineers  already  in  the  Kanagawa  Works;  and  a  program 
section  at  the  division  level  (although  physically  located  in  the  Kanagawa 
Works)  that  had  been  studying  programs  for  pre-Spectra  series  RCA  machines 
produced    in   Japan.    The   core   group   consisted   of   about   60   engineers;    Hitachi 
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hired  another   20   personnel,    for   a   total   of  80.    ' 

Underlying  the  establishment  of  this  department,  according  to  the  head 
of  the  design  section  and  Sakata  s  successor  as  department  manager  in  1969, 
Fujinaka  Satoshi,  was  also  'the  anticipation  that  we  would  develop  software 
as  a  factory  product."  With  the  8000  series  going  on  sale  and  software  for 
the  5020  yet  to  be  delivered,  noted  Fujinaka,  "Work  was  increasing  so 
rapidly  that  the  new  structure  couldn't  catch  up  with  it.  Every  day  was  a 
struggle  with   time.    "'^ 

The  next  logical  step  was  a  software  factory.  In  fact,  rapid  growth  of 
the  computer  division  caused  acute  shortages  of  space  and  personnel  in  both 
the  hardware  and  software  areas.  The  building  housing  the  Kanagawa  Works, 
located  in  Totsuka-cho,  Yokohama,  was  expanded  but  this  was  still 
insufficient.  As  a  result,  Hitachi  established  a  separate  facility  for 
peripherals  (Odawara)  in  1966  and  purchased  another  site  in  Hadano,  an  hour 
or  so  by  train  from  Totsuka,  vshere  it  built  its  current  mainframe  plant 
(Kanagawa  Works).  The  design  and  production  departments  moved  to  Hadano 
in  August  1968,  leaving  most  of  the  company's  software  departments  at 
Totsuka  (a  few  others,  for  some  systems  engineering  and  small-scale 
computers,  remained  within  the  division's  staff  organization  until  later  in  the 
1970s).      In    February    1969,    the  Totsuka   building   was  officially   upgraded  to  a 

separate   factory    --    the    first    software   facility    in    the   world    referred    to   as    a 

••/     t.  "39 

factory.    ■^^ 

According    to    the    managers     who    operated    the     new    factory,     Komoto 

Yukio     (the     first     head     of     the     Software    Works),      Nakatani     Nobuo     (his 

successor),     and    Sakata     Kazuyuki     (who    served    as    deputy    general    manager 

during    the    1970s),    there   were   two    reasons    for   following   this    strategy:       One 
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was  the  acute  shortage  of  software  engineers  and  the  hope  that  centralizing 
software  development  in  a  single  facility  would  bring  about  an  increase  in 
productivity.  Despite    a    nation-wide    search    for    software    engineers,    they 

still  had  considerably  less  than  their  target  to  staff  the  new  factory  in  1969. 
The  second  and  major  reason  was  a  corporate  decision  to  stop  treating 
software  as  simply  an  engineering  service  that  went  along  with  hardware  but 
to  view  it  as  a  separate  product  that  could  and  should  be  produced  and 
inspected,  with  guaranteed  quality,  in  a  more  disciplined  environment.  The 
key  benefit  of  the  factory  approach,  Hitachi  managers  believed,  was  an 
improved    ability   to   control    quality.  Hitachi    managers    such    as    Shibata    also 

believed  they  were  making  a  conscious  departure  from  the  approach  used  at 
RCA,  where  software  quality  was  not  emphasized  and  little  attention  was 
paid  to  fixing  bugs.  Japanese  customers  would  not  tolerate  the  bugs 
discovered  in  RCA  programs,  forcing  Hitachi,  according  to  Shibata,  to  find  a 
better  way  of  guaranteeing   quality. 

Nor  was  the  decision  to  establish  a  software  factory  made  in  a  casual 
manner;  executives  discussed  it  at  the  highest  levels  of  the  company. 
Hitachi  President  Komai  gave  the  final  order  to  organize  the  Software  Works 
as  an  independent  profit  center,  in  keeping  with  Hitachi's  traditional 
organizational  structure  and  control  system.  A  debate  within  Hitachi  ensued 
over  the  nature  and  name  of  the  new  facility;  some  engineers  wanted  to 
establish  a  "Software  Center."  But  President  Komai  intervened  and  ordered 
that  they  "call  it  a  factory.  "^^  This  was  despite  the  fact  that  no  other 
company  in  the  world  had  established  a  factory  for  software  production,  and 
Japanese  university  professors  criticized  Hitachi,  maintaining  that  software 
was     not    sufficiently    understood    to    be    produced    through    engineering    and 
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factory    methods.    -^ 

The  Factory  Architects 

The  central  figure  in  the  development  of  the  factory's  process  and 
quality  control  systems  was  Sakata  Kazuyuki,  the  individual  who  had  served 
as  manager  for  several  key  projects  as  well  as  for  the  system  program 
department  (currently  he  is  a  senior  managing  director  of  Nippon  Business 
Consultants,  a  Hitachi  software  subsidiary).  Sakata  had  entered  Hitachi  in 
1941  from  a  technical  high  school  and  gone  to  work  as  a  machine  operator 
in  the  Totsuka  Works.  After  additional  training  at  Hitachi's  in-house 
engineering  school  and  a  two-year  stint  in  the  army,  he  joined  Totsuka's 
production  engineering  department  in  November  1945  and  began  developing 
standard  times  for  machining  operations  as  well  as  studying  job  tasks, 
scheduling,  and  conveyor  systems  to  improve  productivity.  In  1957,  Sakata 
moved  to  the  accounting  department  and  got  his  first  glimpse  of  a  computer 
--  an  IBM  421  tabulating  machine.  In  I960,  he  was  reassigned  and  made  the 
manager  of  a  new  computer  inspection  section,  which  had  about  30  members. 
When  Hitachi  management  separated  computer  development  from  the  Totsuka 
Works  in  1962  and  established  the  Kanagawa  plant,  Sakata  continued  as 
manager  of  the  inspection  section,  which  was  now  located  within  the 
engineering  department.  The  following  year  he  became  head  of  the  computer 
division's  engineering  service  department,  which  did  systems  engineering  for 
Hitachi  customers.  Then,  in  1965,  with  the  establishment  of  the  system 
program  department,  Sakata  became  responsible  for  software  production  and 
quality   control. 

Sakata's     major     frustrations     were     bugs     in     the     software     Hitachi     was 
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receiving  from  RCA,  and  the  shortage  of  programmers,  which  he  had  to 
divide  among  the  RCA  machines,  the  5020  project,  and  applications  programs. 
A  dozen  Hitachi  hardware  engineers  not  working  on  the  5020  learned  how  to 
write  software  by  studying  and  translating  RCA's  COBOL,  FORTRAN,  and 
ASSEMBLER  manuals  for  the  HITAC  3010  and  4010  machines;  seven  or  eight 
then  continued  in  the  system  program  department  reviewing  the  new 
programs  from  RCA  and  correcting  bugs  before  shipping  the  software  to 
Hitachi  customers.  This  experience,  as  well  as  his  background  in  hardware 
production  management  and  inspection,  and  in  computer  engineering  service, 
convinced  Sakata  that  there  had  to  be  a  better  way  to  produce  programs  and 
prevent  breakdowns  due  to  errors:  setting  the  same  quality  standards  for 
software  as  for  other  Hitachi  products,  and  rejecting  the  notion  that  the 
nature  of  software  was  such  that  there  would  always  be  bugs.  "Thus," 
Sakata    recalled,    "even   though    it  was    software,    we  called    [the   new  facility]    a 

r      4.  "44 

factory.    ^^ 

The  key  individual  who  became  responsible  for  implementing  Sakata's 
basic  ideas  was  Shibata  Kanji,  currently  the  head  of  the  engineering 
department  in  the  Software  Works.  He  first  joined  the  engineering  service 
section  of  Hitachi's  computer  division  in  1964  after  majoring  in  electrical 
engineering  at  Shinshu  University,  and  later  moved  to  the  system  program 
department  and  then  the  production  administration  section  of  the  Software 
Works. 

Shibata  quickly  became  the  in-house  expert  on  software-engineering 
management  soon  after  he  joined  Hitachi.  One  aspect  of  the  company's 
training  program  for  new  engineers  required  them  to  take  several  months 
during   their   second   year  to  write   a   paper  on    a   theme   related  to  their  work. 
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and  then  give  a  presentation.  Shibata  chose  to  collect  data  on  programmers 
working  on  software  for  the  RCA  machines  and  the  5020  --  hovs  much  time 
they  spent  each  day  on  different  activities  and  different  types  of  programs. 
Programmers  did  not  like  being  watched  closely  or  keeping  records,  recalled 
Shibata,  so  they  stopped  doing  this  in  196G.  But  Sakata,  Shibata's  supervisor 
in  the  system  program  department,  read  his  paper  and  decided  this  data  was 
too  valuable  not  to  collect.  Sakata  then  hired  female  employees  to  keep  the 
records,  which  became  the  basis  of  the  Software  Works'  production  planning 
and   control    system.'^"' 


III.    FACTORY  ORGANIZATIONAL  STRUCTURE  AND  MANAGEMENT 
Control   Philosophy 

With  the  decision  to  establish  a  software  factory,  Hitachi  software 
managers  became  obligated  to  adopt  company- wide  accounting  and 
management  procedures  and  thus  innovate  in  software  engineering 
management  by  devising  systematic  controls  on  the  process  flow,  costs,  and 
product  quality.  There  was  little  opportunity,  then,  for  Hitachi  managers  to 
treat  software  as  an  "art"  or  "craft."  In  Hitachi's  hardware  factories,  the 
management  systems  evolved  centering  on  standardization  and  components 
control.  Sakata  and  Shibata  believed  it  was  possible  to  apply  the  same 
concepts   to  software. 

In  particular,  Shibata  wanted  programmers  to  design  modules  that  would 
serve  as  the  equivalent  of  standardized  hardware  parts.  "Around  1970  we 
came  to  believe  that  we  had  to  introduce  a  components  control  system 
similar    to    what    you     find    for     hardware,     and     in    the    Software    Works    we 
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established  a  committee  to  take  this  up  as  a  special  project."  The  committee 
members  soon  realized,  however,  that  "software  is  not  sufficiently 
standardized  to  be  treated  the  same  as  hardware  components  control."  They 
changed  their  priorities  and  decided  that,  first,  they  had  to  find  a  way  to 
standardize  product  design,  just  as  this  had  been  done  in  hardware 
manufacturing,  and  then  worry  about  components  control.  A  special 
committee  then  started  establishing  standards  for  all  activities,  while  the 
original  committee  adopted  the  name  "Structured  Programming  Methods 
Committee,"  believing  that  structured  programming  techniques  would  provide 
a  way  to  standardize  the  software  design  process.  Company  engineers  next 
spent  several  years  studying  these  techniques  from  available  literature,  as 
well  as  analyzing  programs  Hitachi  had  already  written  to  find  ways  to 
improve    the    design     structure.        This    was    before    structured    programming 

became    discussed    more    widely    in     industry    journals    and    adopted    by    other 

46 
companies.    " 

In    addition   to   their   central   objective  of   standardization,    the   experience 

of   Sakata   and   other   Hitachi   managers    in    hardware  production    had   encouraged 

them   to   believe   that    improvements    in    productivity   and   quality    (reductions    in 

bugs)    were    most    likely    to    come    from    better    tools    and    management    systems. 

In    software,    they    viewed    these   as    higher-level    languages    and    modularization 

for    long-term    maintenance,     as    well    as    visible    charts    and    documentation    for 

better    process    control.       Developing    a    "visualized"    production    control    system 

became    an    especially    important    goal,     because    software    engineering    did    not 

involve    visible    raw    materials.       To    pursue    these   objectives,    they    decided    to 

analyze,     and    then     attempt    to    manage,     the    overall     process    of    software 

development    in    much    the    same    way    as    they    saw    hardware    engineering    and 
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manufacturing:  They  developed  factory  systems  that  provided  controls  for 
production  management,  including  man-pov,er,  process,  quality,  and  product 
controls;  and  for  product  engineering,  including  standardization,  design,  and 
inspection.  The  controls  involved  a  mixture  of  manual  and  automated 
support-tools  and  systems,  with  strong  efforts  during  the  late  1970s  and 
1980s   toward   computer-integrated   production.    '      (See   Table) 

Initially,  the  motivation  for  pursuing  factory-type  production  and 
product-engineering  systems  was  to  be  able  to  inspect  software  products,  like 
any  other  product  Hitachi  manufactured,  and  thereby  be  able  to  guarantee 
quality.  But  a  side  benefit  of  the  system  of  controls,  according  to  Shibata, 
turned  out  to  be  the  "minimization  of  problems."  This  has  resulted  in 
significant  improvements  in  productivity,  thus  indirectly  addressing  the 
shortage  of   skilled  programmers.    ° 

Process   Flow  and  Organization 

The  factory  organization  contained  departments  and  functions  similar  tc 
those  in  hardware  manufacturing  plants:  product  planning,  inspection, 
engineering,  accounting,  and  general  affairs,  as  well  as  training.  Hitachi 
managers  did  not  view  the  factory  organization  as  static;  over  time,  they 
consolidated  some  functional  areas,  added  design  departments  as  software 
technology  evolved  (such  as  for  artificial  intelligence  and  computer  graphics), 
and  centralized  all  large-scale  custom  applications  (railways,  banking, 
industrial)    development   in   a   second  facility,    the  Omori   Software  Works. 

Hitachi  engineers  conceived  of  the  software  development  process  in 
much  the  same  way  as  other  software  engineers  around  the  world:  as 
primarily    composed    of    design    and    testing    activities.         Data    on    man-pov\er 
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allocations  (total  number  of  workers)  per  process  at  Hitachi  Software  Works 
ca.  1985  indicates  this  is  an  accurate  conceptualization:  roughly  50  to  55% 
went  into  planning  and  design,  5%  to  coding,  30-35%  to  debugging,  and  about 
10%  to  inspection.    ^ 

The  organizations  and  process  flows  were  somewhat  different  for 
systems  software  as  opposed  to  applications  software.  As  seen  in  the  table, 
the  Software  Works  began  with  three  design  departments  for  distinct  types 
of  programs:  system  development  (custom  applications  engineering),  system 
programs  (basic  software),  and  on-line  programs  (large-scale  real-time 
applications  programs  for  the  National  Railways,  NT&T,  banks,  and  other 
industrial  or  institutional  customers).  For  systems  software,  the  design 
departments  were  responsible  for  design,  program  construction  (coding),  and 
debugging,  with  inspection  done  by  a  separate  department.  At  Omori, 
however,  high  level  design  was  done  by  systems  engineering  departments 
specializing  in  different  industries  or  functional  areas,  and  this  was 
separated  from  program  construction  and  system  testing.  In  this  clearer 
division  of  labor  between  design  and  "manufacturing,"  according  to  Shibata, 
Omori  operated  more  like  a  "factory."  There  was  a  division  of  labor  for 
systems  software  as  well  in  the  sense  that  younger  programmers  were  asked 
to  do  coding,  but  there  was  no  organizational  separation  of  design  and 
program  construction   as  at  Omori. ^" 
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SOFTWARE    PROCESS   FLOW  AND   DIVISION  OF    LABOR^^ 

A      SYSTEMS    SOFTWARE    (Hitachi   Software  Works) 


Pesig n   Departments 
Basic    Design 
Functional    Design 
Structural    Design 
Coding 

Stand-Alone   Debugging 
Combinational    Debugging 
Comprehensive   Debugging 


Inspection   Department 

Initial    Inspection    Planning 


Documentation    Planning 


Inspection    Program  Compilation 
Final    Product    Inspection 


B.    CUSTOM   APPLICATIONS    SOFTWARE    (Omori    Software  Works) 

Sy s t em  Enqinee r i nq   Departments 

System    Proposal    Compilation 

Demonstration 

Estimate 

P n>g ra mm i ng   Depa rtments 
System   Construction/Consultation 
System   Design 
Program    Implementation 
Conversion 
System  Test 


Follow-Up   Service 


Inspectio n   an d  Quality  Assurance 
Final    Inspection 
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SOFTWARE   FACTORY  ORGANIZATIONAL  EVOLUTION 
A.    Hitachi  Software  Works   1969  Organization  Chart^^ 
DESIGN  DEPARTMENTS  ADMINISTRATIVE  SECTIONS 


SYSTEM  DEVELOPMENT 
Design   Groups    (6) 

SYSTEM  PROGRAMS 
Planning  Group 
Design   Groups    (2) 

ON-LINE    PROGRAMS 

National    Railways    (2  Groups) 
NT&T    (4  Groups) 
Banking    (2   Groups) 
Government    (1    Group) 


Administration 
Inspection 
Engineering 

Accounting   and   Control 
General   Affairs 


COMPUTER  TECHNOLOGY  SCHOOL 


B.    Hitachi  Software  Works   1986  Organization  Chart^-^ 


Product   Planning   Department 

DESIGN  DEPARTMENTS: 

No.    1    Systems    Programming 

No.    2   Systems    Programming 

Database   Programming 

Data   Communications    Programming 

Language   Processor 

Artificial    Intelligence 

Computer  Graphics 

Small-Scale  Systems    Programming 


OTHER  DEPARTMENTS: 

Engineering 

Documentation/Manual   Development 

NT&T    Information    Processing   Systems 

Inspection 

Computer  Center  Service 

Software  Education   Center 

General   Administration 

Purchasing 

Accounting   and   Control 

Software  Technology  Center 


C.    Onrori   Software  Works   1987  Organizational   Structure  and   Functions^"^ 

SYSTEM  ENGINEERING  DEPARTMENTSPROGRAMMING  DEPARTMENTS 

Banking  Analysis,    Planning,    Design 

Media  Implementation 

Hospitals  Inspection   &  Quality  Assurance 

Local   Government 

Industrial  OTHER  DEPARTMENTS 

Distribution  Program   Support 

Accounting  Contract  Service   Program 

Payroll  Technical   Support  Center 

Networks  System   Design   Automation 

Tool   Development  Computer  Center 

System   Simulation   Test 
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A  flexible  aspect  of  both  factories,  however,  was  the  ability  of 
managers  to  move  personnel  freely  between  among  groups  within  a 
department,  such  as  if  problems  arose  on  a  given  project.  For  example, 
departments  in  Hitachi  Software  Works  generally  had  between  500  and  600 
people,  with  the  NTlT  department  being  the  largest  (around  900); 
departments  were  then  organized  into  groups  of  about  100  programmers,  with 
sub-groups  of  about  30  members.  Managers  could  also  appeal  to  engineering 
groups  within  each  department  to  add  manpower  to  help  solve  project- related 
difficulties,  or  they  could  appeal  to  the  Engineering  Department  and  the 
Software  Technology  Center  for  problems  or  develop  tools  considered  to  have 
factory-wide   relevance.    "^ 

Staff  Depa rtmcnts  and   Functions 

PRODUCT    PLANNING 

The  Product  Planning  Department  in  the  Software  Works  was  launched 
in  1970  to  centralize  planning  activities  dispersed  among  the  system  program 
department,  the  large-scale  program  area,  and  the  administration  (control) 
section.  Responsibilities  included  planning  for  products  such  as  nev\ 
operating  systems,  beginning  with  OS7,  but  also  for  exports  In  1974,  for 
example,  the  department  set  up  promotion  conferences  to  determine  policy 
for  Hitachi's  M  series,  which  Hitachi  was  designed  to  compete  directly  with 
the  IBM  370  family.  These  activities  included  preparing  for  OEM  exports  to 
Itel  in  the  U.S.  and  studying  how  to  make  the  Hitachi  hardware  fully  IBM 
compatible.  To  assist  in  this  effort,  Hitachi  also  established  in  1972  a 
Computer  Liaison  Office  in  Mountain  View,  California,  which  the  Product 
Planning     Department     in    the    Software    Works    administered    directly.        This 
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office  served  as  an  "information  pipeline"  on  IBM,  replacing  RCA,  and  in 
1978  was  absorbed  by  the  San  Francisco  office  of  Hitachi  America.  "  In  the 
late  1970s,  the  department  became  involved  in  product  pricing  as  Hitachi 
unbundled  software  from  hardware,  and  in  administration  of  overseas 
technical  contracts.    ' 

ENGINEERING    (PRODUCTION   ADMINISTRATION) 

This  department  originated  in  the  engineering  department,  software 
section,  of  the  Kanagawa  Works,  and  was  moved  in  1970  to  the  Software 
Works.  It  began  with  two  sections  (engineering  and  administration)  and  36 
members.  The  engineering  section  served  largely  as  a  liaison  group  for  the 
computer  division,  other  Hitachi  factories,  and  subcontractors,  providing 
explanations  and  documentation  on  software-product  pricing  and  progress  on 
product  development.  The  administration  section  was  responsible  for 
production  management  and  process  control  (scheduling),  as  well  as 
administration  of  the  computer  and  software  centers  attached  to  the  factory. 
This  group  set  standard  times  and  was  responsible  for  cost  control  and 
studying  software  productivity.  It  also  helped  develop  control  systems  to 
monitor  design  and  inspection,  as  well  as  other  tools,  in  conjunction  with 
the  System  Development  Laboratory  (established  in  1975)  and  the  Software 
Technology  Center  (established  in  198X).  General-use  tools  were  always  paid 
for  out  of  the  factory  budget.  Other  sections  of  the  original  engineering 
department  later  became  full  departments:  procurement,  which  purchased 
software     from     overseas     and     Japanese     subcontractors;      and     the 

CO 

documentation/manuals   section.''" 
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INSPECTION 

This  department  originated  with  the  SoftvNare  Works  and  has  followed 
the  strategy  of  developing  inspection  and  control  techniques  based  on  actual 
operating  data.  The  manager  of  this  department  reports  directly  to  the 
factory  head,  as  in  all  Hitachi  factories.  In  addition  to  overseeing  all  testing 
and  debugging,  an  important  tool  has  been  the  "needle  probe,"  to  identify 
bugs  while  a  program  is  in  development  and  provide  data  to  revise  estimates 
and  formulate  countermeasures  to  correct  the  problems.  The  inspection 
department  also  operated  the  SST,  established  in  1977,  which  simulated  user 
conditions  and  used  input/output  and  circuit  defect  generators  to  detect 
bugs;  organized  the  design  review  task  forces,  which  include  reviewers  from 
several  different  departments,  including  inspection;  evaluated  the  performance 
of  programs  at  customer  locations;  took  charge  of  maintenance;  compiled 
information  on  bugs  and  developed  methods  of  testing  for  potential  defects 
and  developed  the  factory's  bug  forecasting  system.  In  addition,  the 
department  had  responsibilities  for  programmer  training  and  helped  develop 
support   tools.  ^^ 

ACCOUNTING    AND  CONTROL 

The  members  of  this  department  set  up  and  have  maintained  the 
factory's  cost  accounting  system.  A  major  problem  in  the  beginning  was 
how  to  treat  orders,  sales,  and  income.  Management  then  decided  to  total 
development  expenses  for  systems  software  after  a  project's  completion  and 
then  charge  these  back  to  the  Kanagawa  Works.  Payments  for  applications 
programs  for  customers  were  included  with  the  hardware;  the  Software  Works 
received    payments    by    submitting    in-house    order    tickets.        Essential    to    the 
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calculations    were    the    standard    times    for    all    software    development    activities, 
set  by  the  engineering    (production   administration)    department.    ^ 

SYSTEMS   ADMINISTRATION    (OMORI    SOFTWARE  WORKS) 

This  department  originated  in  1973,  from  the  computer  division's 
systems  consultation  department,  which  developed  large-scale  applications 
programs  for  the  government  and  private  customers.  Fujimoto,  the  head  of 
the  Software  Works,  and  Sakata,  the  deputy  general  manager,  moved  this 
divisional  department  to  the  Software  Works  as  part  of  their  effort  to 
centralize  and  standardize  design  activities,  in  preparation  for  the 
introduction  of  the  first  M-series  mainframes  in  1974,  which  required 
additional  personnel  to  rewrite  programs  to  run  on  them.  The  institution  of 
SC  (system  consultation)  standard  times  corresponded  to  the  move  of  this 
department  to  the  Software  Works.  The  department  also  took  over 
responsibilities  for  financial  controls  for  leased  systems."'  Hitachi  then 
moved  the  systems  administration  department  to  the  Omori,  Tokyo  site,  and 
in   1985  made  this   a   separate  factory  for  applications   programs. 

MANPOWER  CONTROL 

The  basic  tool  for  manpower  control  in  Hitachi's  software  factories  is 
standard  times  for  all  phases  of  the  development  process,  beginning  with 
basic  design.  Since  the  establishment  of  the  Software  Works,  a  committee  of 
Hitachi  managers  has  revised  these  once  per  year,  to  keep  up  with 
improvements  in  programmer  productivity.  This  attempt  to  study  and 
discipline  an  engineering  activity  began  in  the  mid-1960s,  when  programmers 
in   the   Kanagawa  Works   began    recording  data  on   computer  time  and  personnel 
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required  to  develop  particular  programs.  Guided  by  Shibata,  Hitachi  engineers 
had  enough  actual  data  and  confidence  by  1967  to  establish  formal 
procedures  for  estimating  both  labor  and  machine  hours  for  program 
development,  initially  placing  this  information  on  job  tickets.  The 
inauguration  of  the  Softv^a^e  Works  in  1969  then  made  it  necessary  to  adhere 
to  Hitachi  s  company-wide  budgeting  and  cost-accounting  procedures,  which 
used  standard  times  as  basic  accounting  units  for  all  engineering  and 
production    activities. 

"We  were  perplexed,"  recalled  Sakata,  but  they  set  up  a  committee  that 
succeeded  in  drawing  up  formal  standard  times  for  each  activity  and  for 
each  class  of  programmers,  based  on  their  training  and  experience.  The 
standard  times  consisted  of  debugged  program  steps  per  day  or  month,  and 
took  into  account  factors  such  as  the  type  of  program  being  written  and  the 
language  being  used.  They  collected  the  data  in  a  "red  book"  that  became, 
in  the  early  1S70s,  the  basis  for  the  factory's  current  cost  accounting  and 
planning  systems.  Hitachi  instituted  these  controls  for  software  several 
years  before  IBM  began  promoting  the  use  of  standard  times,  although  the 
System  Development  Corporation  had  published  some  materials  discussing  how 
to  devise  standard  times  for  software  during  1967-1968  and  these  provided 
several   suggestions   to  Shibata. °^ 

Hitachi  managers  early  on  realized  that  systems  software  development 
required  a  different  set  of  activities  than  customized  applications  software. 
To  deal  with  this  problem,  they  established  SC  (system  consultation)  standard 
times    in    1973.  The    systems    engineering    groups    also    developed    separate 

tools  and  systems  such  as  HIPACE  (Hitachi  Phased  Approach  for  High 
Productive    Computer    System    Engineering)    to   standardize   their   proposals    and 
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to  aid  in  design  automation.  The  evolution  of  different  standards  and  tools 
made  it  relatively  easy  to  move  the  applications  departments  to  the 
independent  Omori   site. 

Planning  and  scheduling  improved  significantly  soon  after  the  factory 
was  established,  through  the  compilation  of  actual  data  for  each  phase  of 
the  development  process,  and  continual  refinement  of  planning  techniques. 
Accurate  programmer  classifications  were  considered  essential  to  both  the 
planning  and  budgeting  systems,  which,  for  each  project,  took  into  account 
the  experience  and  potential  output  of  team  members.  Programmer 
classifications  were  determined  largely  but  not  entirely  by  their  length  of 
service  in  the  company.  Seniority  was  a  fairly  accurate  indicator  of 
performance,  according  to  Sakata,  because  actual  data  showed  that  coding 
speed  increased  markedly  with  experience.  But,  at  any  given  time,  only 
between  20  and  30  percent  of  programmers  actually  met  standard  times,  and 
it  generally  took  2  to  3  years  to  reach  standard  times  for  coding  (and  longer 
for  design) . 

Programmers  were  also  tested  before  managers  raised  their  official 
classifications.  They  were  made  to  take  certain  courses,  and  then  tested  at 
the  completion  of  each  course.  In  addition,  all  programmers  twice  a  year 
were  tested  through  competition  in  contests,  where  they  had  to  write  flow 
charts  and  code  to  solve  certain  problems.  The  contests  involved  both 
individuals  and  groups,  and  management  recorded  the  results  in  a  data  base 
as   a   reference  for  future  planning  and   scheduling.^ 

PROCESS  CONTROL 

Establishing   a   capability   for  accurate  planning   and   process   control   were 


29 


his  most  enduring  problems,  claimed  Sakata.  These  were  especially  important 
because  Hitachi  s  computer  division  sales  department  would  always  announce 
new  computer  products  and  give  out  specifications  before  the  Software 
Works  had  developed  the  systems  software.  This  placed  a  tremendous  burden 
on  softvsare  managers  to  meet  their  targets.  Customers  also  wrote  their  own 
applications  programs,  based  on  the  advance  specifications,  and  became  very 
upset  if  the  systems  software  was  delayed  or  if  Hitachi  changed  the 
specifications . 

The  Software  Works'  process-control  system  monitors  the  status  of  each 
project  through  documents  covering  the  first  half  of  the  development 
process.  Large  projects  include  several  hundred  people,  divided  into  teams  of 
about  thirty  with  responsibilities  parcelled  out  equally  to  team  members. 
Time  and  manpower  estimates  rely  on  actual  data  for  past  projects,  including 
the  annually    revised   standard  times. 

For  example,  scheduling  for  a  given  project  first  involves  the  system 
architects  determining  the  general  functional  specifications  and  how  many 
program  steps  this  will  take.  This  is  the  most  difficult  part  of  scheduling, 
according  to  Shibata,  and  thus  the  most  error  prone.  Then  they  look  to 
standard  times  data  for  each  phase  of  the  development  process  and  calculate 
a  standard  time  objective  for  the  entire  project.  They  next  look  at  the  skill 
levels  and  particular  programming  experiences  of  the  employees  available  for 
the  project.  Using  the  standard  times  as  a  reference,  they  work  out  a 
schedule  based  on  required  program  steps,  man-months  adjusted  for  skill  and 
experience   levels,    and   computer   time. 

At  the  inception  of  the  factory,  managers  began  using  simple  arrow 
diagrams    and    then    a    computerized    diagramming    tool,     PERT    Network    System 
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(PNET),  to  keep  track  of  projects  and  draw  up  a  master  schedule.  Hitachi 
linked  this  experimentally  with  a  planning  simulation  program  in  1971,  HICAP 
(Hitachi  Computer- Aided  Planning).  It  did  not  prove  to  be  especially 
accurate,  however,  and  involved  other  problems.  Most  serious  was  that 
letting  the  computer  control  the  schedule  was  too  lax,  since  parts  of  a 
program  often  have  to  be  completed  before  other  work  can  continue; 
managers  preferred  to  deal  with  these  types  of  problems  through  personal 
negotiations.  In  addition,  during  project  progress  meetings  (formalized  in 
1973-1974  and  which  met  once  a  month  to  discuss  problems  and  potential 
solutions),  they  found  it  convenient  to  use  arrow  diagrams  on  paper,  because 
of  all  the  schedule  changes  they  usually  made.  Hitachi  thus  went  back  to 
manually  written  arrow  diagrams  for  process  planning,  until  the  factory 
introduced  CAPS  as  an  on-line  production  control  system  in  1978  to  track 
the  actual  progress  of  completing  modules  and  documentation,  and  of 
debugging  and  design  review.  This  system  involved  the  assignment  of  every 
programmer  to  a  specific  terminal  as  well  as  a  central  data  base  to  keep 
track  of  the  process  flow,  mainly  through  the  completion  of  documentation.""' 
In  the  debugging  process,  the  basic  control  mechanism  has  been  check 
lists,  which  indicate  problems  and  progress  toward  solutions,  including  from 
1973-1974  a  system  of  tickets  (or  tags)  for  accompanying  documents. "° 
Hitachi  used  PX  tickets  to  accompany  daily  control  charts  during  debugging, 
and  PY  tickets  for  daily  control  charts  during  inspection.  PZ  tickets 
accompanied  control  charts  identifying  specific  defects  or  bugs,  while  PW 
tickets  designated  control  charts  used  during  planning,  design,  and  coding. 
Other  tickets  indicated  the  state  of  work-in-process,  and  progress  in 
correcting    defects.     Overall    monitoring    of    the    debugging    process    was    also 
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incorporated   within    CAPS. 

To  determine  what  percentage  of  a  project  has  been  completed, 
managers  submit  reports  on  completion  of  modules.  If  a  program  is  designed 
to  have  100  modules,  for  example,  and  80  are  completed,  then  they  consider 
the    project    8Cfc    done.  One    of    the    results    of    the    control    systems    used    at 

the  Softv\are  Works  is  that,  if  projects  are  falling  behind,  managers  can  add 
people  --  not  just  anyone,  but  the  best  people  available  --  and  generally 
finish  close  to  the  target.  This  was  because  the  factory  environment 
facilitated  rapid  understanding  of  projects."^  In  contrast,  IBM's  experiences 
with  the  360  operating  system  development  was  that  adding  people  tended  to 
make  projects  later,  due  to  the  communication  time  needed  to  familiarize 
new   personnel .  ^ 

QUALITY    CONTROL 

Hitachi  engineers  defined  quality  control  for  software  as,  first, 
preventing  the  creation  of  bugs  in  the  design  stage,  and,  second,  meeting 
performance  specifications.  These  two  factors  directly  impact  the  customer 
and  so,  according  to  Shibata,  Hitachi  gave  them  primary  importance.  Two 
other  features  of  quality  that  directly  affected  the  manufacturer  were 
maintainability  and  portability  of  a  program,  so  Hitachi  also  tracked  these 
measures     secondarily.'  To    improve    quality    control     in    the    mid-1970s, 

Sakata,  Shibata,  and  other  factory  managers  decided  to  adopt  structured 
design  methods,  high-level  languages,  and  formal  systems  for  quality  and 
process  control,  and  product  engineering.  These  facilitated  long-term 
maintenance  as  well  as  short-term  productivity  by  making  it  possible  to 
divide  job   tasks   more   easily   and   to  test   completed   modules   and   programs. 
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In  1971,  the  factory  instituted  control  charts  indicating  the  generation 
of  bugs  and  status  of  corrections,  as  well  as  a  "needle  probe"  technique, 
developed  by  Sakata,  to  test  a  program  being  developed  when  about  60%  was 
completed,  and  then  revise  the  overall  bug  estimates.'^  In  1972,  Hitachi 
added  another  ticket-control  system:  P  tickets  to  designate  program 
changes,  and  B  tickets  to  indicate  corrects  of  bugs.  In  1974,  these  were 
linked  to  the  PX-PW-PZ  process-control  ticket  system,  to  simplify  project 
control  and  estimating.  At  the  same  time,  the  needle  probe  tool  and  data  on 
actual  bug  generation  for  different  types  of  programs  became  the  basis  of  a 
time-series  statistical  program  for  forecasting  bugs  instituted  in  1975, 
FORCST.  This  also  provided  programmers  with  examples  of  bugs  in  different 
types  of  software,  to  help  them  avoid  making  similar  errors.'"^  Included  as 
part  of  the  quality  control  effort  were  also  design  review  sessions  from 
around  1974  (particularly  used  for  applications  programs  where  Hitachi  had 
to  meet  customer  specifications).  In   addition,   the  system-leaning  practices, 

focusing  on  particular  system  design  problems  and  solutions  that  seemed 
instructive  to  present  to  all  employees  in  the  Software  Works,  supplemented 
other  quality  assurance  activities. 

Following  the  practices  of  other  Hitachi  factories,  the  Software  Works, 
with  assistance  of  engineers  from  the  System  Development  Laboratory, 
formalized  as  well  as  automated  its  quality  control  tools  and  procedures 
during  the  mid-1980s,  referring  to  its  system  as  "SQE"  (Software  Quality 
Evaluation).  This  maximized  not  subjective  measures  of  quality  but  program 
"reliability"  (shinraisei,  and  consisted  of  a  set  of  procedures  and  tools  to 
"support  and  improve"  reliability  by  determining  the  number  of  defects  and 
the   software   and   providing   quick    analysis   of   the   causes   of   errors    and   then 
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feedbacl-  to  make  corrections  and  prevent  similar  errors  by  predicting  and 
correcting  errors  before  products  reach  the  customer.  The  objective  was 
continual  improvement  in  the  level  of  "built-  in"  (tsukurikonii)  design  quality. 
Previously,  quality  control  primarily  involved  the  statistical  evaluations  of 
finished  programs,  without  systematic  error  analysis,  feedback  into  design,  or 
control   over   future   design   efforts. 

Two  basic  policies  underlay  the  SQE  system.  One  was  that  the  error 
analysis  should  involve  a  broad  number  of  measures  and  sufficient 
information  to  allow  useful  feedback  for  all  phases  of  development,  from 
initial  design  through  inspection.  These  measures,  tools,  and  analysis 
techniques  \^e^e  also  supposed  to  be  sufficiently  flexible  to  adapt  to  changes 
in  programming  environments  over  time.  The  second  was  that  the  entire  set 
of  procedures  and  tools  should  be  easy  to  use  for  everyone  involved  in 
development  of  the  software;  therefore,  Hitachi  made  the  tools  available  for 
personal  computers.  It  should  be  noted  that  these  two  characteristics-- 
defect  analysis  and  feedback  to  design  to  build  quality  into  future  products, 
and  simplification  of  tools  and  procedures  to  make  sure  they  were  used 
widely,    insuring    at    least   some  measure  of   success    --    were   both    characteristic 

of     Japanese     quality     control     practices     in     other     "hard"     manufacturing 

7f> 
industries  .  '° 

The    basic    procedure    followed    was    to     (1)     use     reports    on     bugs    from 

customers     to    estimate     how    many     latent     defects     existed,      (2)combine    this 

information   with    in-house  data  on   bugs    uncovered,    (3)    predict  the   number  of 

defects    in    new,    similar    products,    and    (4)    attempt    to    locate    these    "built-in 

errors"   through   testing.      As   long  as  a  product  type  and   its   user  environment, 

as    well    as    its    workforce,    did    not    change    too    much,     Hitachi    engineers    felt 
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confident  they  could  use  historical  data  to  predict  latent  bugs  in  new 
programs,  particularly  since  the  data  captured  made  it  possible  to  revise 
estimates  continually. 

Several  simple  statistics  were  considered  most  useful  in  estimating  and 
analyzing  errors:  development  size  (number  of  steps  or  lines  of  code); 
program  processing  content  and  structure;  program  development 
configuration;  percent  of  the  program  written  in  high-level  languages; 
number  of  design  man-hours  given  the  size  of  the  program;  number  of  test 
man-hours  given  the  size  of  the  program;  number  of  checklist  items  given 
the  size  of  the  program;  comparison  of  the  estimated  and  actual  sizes  of  the 
program;    patterns   formed   by   bugs   detected. 

The  SQE  tool  set  consisted  of  three  subsystems  --  design  quality 
estimation,  test  quality  estimation,  and  comprehensive  quality  estimation-- 
each   covering   different   phases  of  the  development   process. 

The  design  quality  estimation  subsystem  was  first  used  in  the  planning 
stage.  For  design  reliability,  first,  a  table  was  drawn  up  for  each  new 
program  listing  the  number  of  bugs  expected  to  be  in  the  software  and  the 
number  detected  as  development  progressed.  Second,  a  reliability  checklist 
was  used  to  make  sure  the  software  performed  the  basic  functions  its  was 
designed  for.  Third,  as  part  of  the  error  analysis  procedures,  a  "quality 
objectives  establishment"  program  was  written  to  model  the  occurrence  of 
bugs,  using  coefficients  drawn  from  historical  data  on  factors  such  as 
program  size,  processing  content  and  structure,  percent  written  in  high-level 
languages,    number  of  man-hours   spent  on   design   and  testing. 

The  test  quality  estimation  subsystem  was  use  to  evaluate  quality  during 
the   different  testing   steps.      A   QC   graph   chart  actual   bugs   detected   on   one 
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axis  against  estimated  bugs  likely  to  occur  in  different  stages;  this  made  it 
possible  to  monitor  visually  progress  in  error  detection,  as  well  as  provide 
immediate  "feedback"  to  design  and  "feedforward"  to  improve  later  testing-- 
before  a  product  was  completed.  To  track  the  data  on  actual  bugs  versus 
estimates  at  the  completion  of  each  development  phase,  and  to  generate 
estimates  on  how  many  bugs  were  likely  to  remain  undetected,  Hitachi  used 
a   program   called    FRCST. 

The  comprehensive  quality  estimation  subsystem  was  used  in  final 
inspection.  This  used  data  generated  by  the  other  two  subsystems  to 
evaluate  a  program  on  the  basis  of  eight  criteria  covering  product  design, 
product   quality,    and   operating   quality. 

PRODUCT   CONTROL 

This  consisted  of  a  formal  system,  started  by  the  system  program 
department  in  the  Kanagawa  Works,  for  both  storing  program  source  files 
and  accompanying  documentation  for  future  reference,  either  to  correct  bugs 
or  to  add  enhancements.  In  1976,  Hitachi  started  the  practice  of  keeping 
copies  of  all  programs  in  a  separate  location  to  guard  against  destruction 
from   earthquakes   or   accidents.'' 

STANDARDIZATION 

In  addition  to  standard  times,  from  the  inception  of  the  Software 
Works,  Hitachi  managers  made  "job  standardization"  a  top  priority.  They  did 
not  establish  long-term  fixed  standards,  because  personnel  and  technology 
were  changing  continually.  But  the  standards  establishment  committee 
initially     met     almost    weekly    to    determine    what     short-term    work     standards 
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should  be  and  codified  these  as  the  Hitachi  Software  Standards  (HSS).  This 
entire  effort  involved  a  deliberate  attempt  to  standardize  software  as  Hitachi 
factories  standardized  the  development  and  production  of  material  products; 
specifically,  managers  tried  to  prevent  programmers  from  designing,  coding, 
and  documenting  software  products  in  different  ways.  In  Shibata's  opinion, 
standardization  of  the  entire  process  flow  was  probably  the  most  important 
technique  Hitachi  found  to  raise  productivity,  particularly  when  combined 
with  high-level  languages  and  group-programming  support  systems  such  as 
CAPS.  The  fewer  bugs  that  resulted  was  one  advantage;  another  was  that 
standardized   documentation   made   inspection   easier." 

According  to  the  official  factory  history,  the  standardization  effort  was 
extremely  difficult  and  not  very  successful  at  first.  Over  time,  however, 
factory  managers  succeeded:  The  effort  depended  on  the  establishment  of  a 
structured  design  method  in  1973  to  facilitate  program  maintenance  and 
portability,  despite  the  lengthier  programs  that  often  resulted.'^  At  the 
same  time,  the  factory  instituted  a  standardized  "components  [modules] 
control  system"  and  then  in  1977  a  general-use  software  tools  registration 
and  control  system.  Meanwhile,  the  factory  published  standard  coding 
manuals  for  each   programming   language   used   in   the  facility."^ 

The  structured  programming  method  Hitachi  adopted  began  with  a 
standardized  approach  to  design:  (1)  determination  of  user  requirements;  (2) 
determination  of  external  specifications  (the  program's  logic  structure);  (3) 
determination  of  internal  specifications  (the  program's  "physical"  structure); 
(4)  manufacturing  (coding);  and  (5)  inspection  (testing  and  debugging).  The 
logic  structure  represented  the  functional  layers  of  a  program  and  the 
interconnections    (input/output)    between    those    layers.        First,    programmers 
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wrote  specifications  in  natural  language  and  used  an  in-house  tool,  CEG 
(Cause-Effect  Graph),  and  decision  tables  to  identify  inconsistencies  or  flavss 
in  the  logic  structure.  They  then  broke  down  the  object  function  into 
partial  functions  to  develop  algorithms  to  implement  the  desired 
specifications.  The  physical  structure  represented  the  actual  modules  making 
up  the  program  (their  hierarchical  arrangement  as  well  as  interconnections) 
and  data  (data  hierarchies,  data  and  module  interconnections,  and  data-point 
relationships)  . 

Hitachi's  major  design  objectives  were  (1)  to  match  the  physical 
structure  as  closely  as  possible  to  the  logic  structure;  (2)  to  standardize  the 
physical  structure;  and  (3)  to  make  the  elements  of  the  physical  structure  as 
independent  as  possible.  This  latter  principle  required  each  module  to  have 
only  one  input  and  one  output,  and  each  module  to  be  in  effect  a  "closed 
subroutine  "  Documentation  also  followed  a  standardized  format.  In  addition, 
several  support  tools  relied  directly  on  the  standardized  design  structures. 
AGENT  (Automated  Generator  of  External  Test  Cases),  for  example, 
automatically  generated  test  items  from  the  cause-effect  diagrams  and  served 
as  a  logic-design  support  tool.  ADDS  (Automated  Design  and  Documentation 
System)  served  as  a  design-support  tool  for  the  physical  structure  by 
analyzing   design    information   and   generating   documents    in   graphic   form.° 

Related  to  standardization  was  the  capability  to  reuse  modules 
developed  for  both  system  and  applications  programs.  Since  standard  times 
did  not  assume  a  programmer  would  reuse  software,  doing  this  allowed 
programmers  to  meet  or  surpass  standard  times,  and  helped  managers  meet 
cost  or  scheduling  targets  more  easily  than  without  reusing  modules. 
Potential    reusability    was    considered    at    the    very    beginning    of    designing    a 
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program,  and  facilitated  through  the  standardization  of  design  through 
structured   programming. 

The  tradeoffs,  according  to  Shibata,  involved  performance  and 
enhancements;  structured  programs  designed  to  contain  reusable  parts  did  not 
always  perform  as  well  as  newly  written  programs.  In  fact,  a  general  rule 
Hitachi  used  was  that,  if  they  had  to  revise  30%  of  the  code  in  a  module, 
then,  in  terms  of  functional  performance,  it  was  better  to  write  the  module 
needed  from  scratch.  Only  in  1985  did  Hitachi  managers  require  programmers 
to  start  keeping  data  on  how  much  code  they  were  reusing,  although  survey 
data  in  the  previous  paper  ranked  Hitachi  in  the  high  category  for  this 
measure,  exceeded  only  by  Toshiba,  which  was  over  50%  (See  Appendix  table 
on  "Reusability  Analysis").  For  new  releases  of  systems  software,  the 
reusability  rate  was  about  90%.°"^  The  most  opportunities  for  reusability, 
however,    Hitachi   viewed   as   being   in   applications   programs. 

In  addition,  considered  as  part  of  the  standardization  and  reusability 
effort  were  a  series  of  systems  to  facilitate  the  transfer  of  programs  among 
different  machines.  HIPAL  (Hitachi  Program  Application  Library),  an  on-line 
data  base  of  applications  programs  and  utilities,  was  first  set  up  within  the 
computer  division  in  1968  and  then  transferred  to  the  Software  Works  in 
1970.  A  tool  for  translating  programs  for  different  machines,  HITRAN 
(Hitachi  Translation  Program  Library),  was  separated  from  the  HIPAL  system 
in  1977.  Both  of  these  were  for  in-house  use.  HILINK  (Hitachi  Users' 
Program  Library  Network)  was  a  separate  system  launched  in  1975  that  made 
it  possible  for  Hitachi   customers  to  exchange  programs   they  had  written.'" 

TRAINING 


39 


Training  was  integral  to  standardization  and  the  general  success  of  the 
factory  effort.  Consequently,  an  education  program  was  set  up  along  with 
the  Softv.are  Works.  Hitachi  hired  both  software  engineers  who  had  studied 
in  the  U.S.,  as  well  as  high-school  graduates  which  the  company  had  to  tram 
itself.  But  the  expansion  of  Software  Works  personnel  from  348  in  1959  to 
over  900  in  1971  created  a  severe  strain  on  instructors;  a  temporary  solution 
was  to  make  greater  use  of  large  meetings,  as  well  as  use  the  results  of 
tests  based  on  the  Hitachi  Software  Standards  and  contests  among  the 
programmers,  to  judge  the  abilities  of  programmers.^  Managers  recorded 
the  results  of  these  tests  and  contests  and  used  them  (along  with  length-of- 
service  information)  to  classify  programmers  as  an  aid  in  estimating  time  and 
cost   schedules."^ 

The  education  and  classification  scheme  extended  for  12  years  in 
Hitachi,  after  which  individuals  received  the  grade  of  chief  programmer  or 
system  engineer,  depending  on  whether  they  were  in  systems  software  or 
applications  software.  During  the  first  year  in  the  Software  Vvorks, 
employees  were  classified  as  trainees  and  took  courses  in  introductory 
computer  science  and  basic  programming.  They  remained  classified  as 
"junior"  programmers  or  system  engineers  from  the  second  through  fifth 
years  in  the  factory,  during  which  time  they  received  additional  courses. 
Programmers  with  between  six  and  ten  years  of  experience  were  designated 
junior  leaders  and  received  middle-level  courses.  Between  their  ninth  and 
tenth  years,  programmers  rose  to  the  status  of  planners  or  sub-leaders,  while 
undergoing  advanced  training.  Chief  programmers  continued  their  education 
and     studied     subjects     such     as     software     reliability,     use    of     design     review, 

or 

semiconductors,    and  computer   network  technology. 
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There  was  a  distinction  between  the  systems  and  applications  factories, 
however.  In  Hitachi  Software  Works,  where  there  was  no  organizational 
separation  of  program  design  from  program  construction  (implementation), 
young  employees  who  started  out  doing  coding  eventually  could  rise  up  to 
become  designers.  In  Omori,  however,  there  were  separate  career  paths  for 
system     engineers     versus     specialists     in     implementation.  Within     the 

implementation  area,  a  young  employee  might  move  up  from  doing  simple 
coding  to  detailed  design  and  planning,  but  would  not  normally  switch  to  the 
system  engineering  area.  The  reason  was  that  Hitachi  managers  felt 
implementation  and  systems  engineering  for  outside  customers  required 
specific  and  different  sets  of  skills,  in  which  employees  should  specialize, 
although  all  systems  engineers  generally  spent  about  two  years  working  in 
program   implementation   before  moving  over  to  the  high-level   design   area."' 


IV.   THE  TOOL  SET 

The  initial  essence  of  the  factory  infrastructure  at  Hitachi  was 
primarily  a  combination  of  policies  to  promote  standardization  and  the  use  of 
"good"  practices  such  as  structured  design.  A  set  of  tools  to  facilitate 
division  of  labor  and  group  programming  evolved  afterward,  largely  in 
response  to  several  problems  in  software  management  that  appeared  to  defy 
complete  solution  through  management  alone.  A  Hitachi  memorandum  cited 
six   areas  of  specific  concern: 

1.  The  invisible  nature  of  the  production   process 

2.  Increasing   scale,    complexity,    and  diversification  of  program  functions 
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3.  Pressure   for   higher    reliability 

4.  Difficulty   of    improving   production   efficiency 

5.  Shortage    of    software    designers,    especially    experienced    designers,    and 
managers 

6.  Increased   work    hours   for   management.    ° 

The  response  engineers  at  Hitachi's  Systems  Development  Laboratory 
and  at  the  Software  Works  arrived  at  during  the  late  1970s  was  to  develop 
computer-aided  systems  for  functional  support  (such  as  design,  coding,  and 
testing)  and  group  programming  in  general.  The  factory's  policies  for 
standardization,  design,  and  inspection  functions  for  systems  software  were 
integrated  through  CASD  (Computer-Aided  Software  Development  System); 
and  the  policies  for  man-power,  process,  and  quality  control  through  CAPS 
(Computer-Aided  Production  Control  System  for  Software).  Both  CASD  and 
CAPS  relied  on  various  subsystems  or  support  tools,  and  standardized 
methods.  They  themselves  also  evolved  into  a  broader  effort  labelled  ICAS 
(Integrated  Computer-Aided  Software  Engineering  System),  aimed  at  full"> 
integrating  product-engineering  and  production-management  tools  and 
act i  vities  .  °^  The  System  Development  Laboratory  has  directed  the 
development  of  these  technologies,  with  the  cooperation  of  the  Engineering 
Department  in  the  Software  Works  in  areas  related  to  production  and  quality 
control.  90 

Computer-Aided   Software  Development  System   (CASD) 

CASD  was  mainly  a  response  to  the  increasing  size  and  complexity  of 
software    programs    and    grew    out    of    a    design    and    debugging    tool     Hitachi 
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developed  during  1975-1977  to  centralize  controls  for  supporting  and 
standardizing  design  through  the  use  of  structured  programming,  high-level 
languages  for  system  construction,  multiple  and  remote  computer  sites,  and  a 
central  program  library.^'  After  1979  it  became  also  a  tool  for  reliability 
improvement,  evolving  increasingly  in  parallel  and  with  linkages  to  CAPS, 
which  standardizes  a  variety  of  technologies  and  activities  to  improve 
control  over  manpower  planning  and  scheduling  as  well  as  cost,  process 
flows,    and   quality.    ^ 

There  were  two  basic  assumptions  underlying  CASD:  One  was  that 
labor  productivity  in  software  could  be  improved  by  standardizing  the  tasks 
in  each  phase  of  development  and  then  utilizing  support  tools.  Second  was 
that  performance  could  be  improved  not  only  through  standardization  but 
also  through  automating  these  support  tools  for  each  phase  of  the 
development  process  and  then  integrating  them  into  a  single  system.  This 
was  an  attempt,  in  the  words  of  the  architects  of  the  system,  to  "modernize" 
as  much  as  possible  of  what  has  usually  been  considered  a  manual  activity, 
supported  only  with   tools   for  discrete  parts  of  the  development  process.^'' 

Structurally,  CASD  included  three  interconnected  support  subsystems, 
for  design,  programming,  and  testing.  The  design-support  subsystem 
constructed  the  design  documentation  and  analyzed  the  design  specifications. 
The  programming-support  subsystem  made  it  possible  to  write  the  system 
using  a  high-level  language,  and  analyzed  the  results.  The  testing-support 
subsystem  then  helped  devise  the  test  items  and  run  the  program  being 
tested,  as  well  as  evaluate  the  comprehensiveness  of  the  tests  after  they 
were   run. 

The   design-support    subsystem    relied   on    a    structured-programming   tool 
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called  Automated  Design  and  Documentation  System  (ADDS)  as  well  as 
Hitachi's  Module  Design  Language  (MDL).  MDL  made  it  possible  to 
standardize  and  formalize  design  specifications  at  the  module  level;  the  ADDS 
system  placed  this  documentation,  as  well  as  corrections  or  changes,  into  a 
central  database,  and  checked  for  obvious  errors,  thereby  assisting  in  the 
design  review  process.  Printers  and  terminals  provided  the  capability  to 
"visualize'  the  design  documentation.  The  tables  and  charts  produced  by 
ADDS  covered  areas  such  as  the  functional  layered  structure  of  a  program, 
module  specifications,  the  data  flow  path,  module  connections,  and  summaries 
of  the  modules,    functions,    and  changes. 

The  programming-support  subsystem  relied  on  a  standardized  language 
for  coding,  the  Hitachi  Programming  Language  (HPL).  This  also  facilitated 
design  review.  HPL's  main  components  were  a  compiler  and  what  H'tachi 
called  the  Static  Code  Analysis  (SCAN)  system.  Coding  reviews  were  supposed 
to  catch  program  bugs  as  early  as  possible  and  also  provide  a  way  to 
examine  the  program  logic.  Hitachi  engineers  were  frustrated  because  this 
was  largely  a  manual  process,  and  was  affected  significantly  by  the  different 
levels  of  ability  of  the  programmers.  To  address  these  problems,  the  SCAN 
system  received  static-code  analysis  data  from  the  HPL  compiler  and  put  out 
various  reports  for  use  in  the  coding  review.  These  reports  analyzed  the 
program  control  structure  in  graphic  form,  the  program's  data  structure,  and 
the  module  control  structure  and  relationship  between  modules  and  data. 
Then,  SCAN  checked  the  results  of  these  analyses  with  design  information 
from   ADDS. 9^ 

The     testing-support     subsystem    was     intended     to    tackle    problems    of 
quality     control     and     productivity     simultaneously     by     facilitating     the 
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identification  of  bugs  and,  correspondingly,  the  reduction  of  man-hours 
devoted  to  testing.  This  subsystem  had  four  objectives.  One  was  to  clarify 
in  detail  the  design  specifications,  on  the  assumption  that  the  test  items  had 
to  determine  the  conformance  of  the  program  to  its  specifications.  Another 
was  to  establish  testing  standards  for  a  given  program,  recognizing  that  it 
was  impossible  to  test  all  potential  operating  conditions.  In  addition,  the 
subsystem  was  designed  to  automate  as  much  of  the  testing  process  as 
possible,  as  well  as  evaluate  the  comprehensiveness  of  the  tests.  Several 
other  tools  --  Cause  and  Effect  Graphs  (CEG),  Automated  Generator  of 
External  Test  Cases  (AGENT),  HPL  Test  and  Debugging  system  (HPLTD),  and 
Test  Coverage  Manager  (TESCO)  --  were  integrated  within  the  system  to 
perform  these  objectives.^" 

Computer-Aided   Production  Control  System   (CAPS) 

As  with  CASD,  CAPS  development  was  inspired  by  several  persistent 
problems.  Hitachi  managers  wanted  greater  standardization  and  control  of 
the  process  flow,  delivery  times,  quality,  and  overall  costs.  In  particular, 
CAPS  focused  on   the  following   areas: 

1.  Collection     and     analysis    of    management    or     process-control     data     in 
accordance  with   the  structure  of  a   program 

2.  Chronological   analysis  of  each   type  of  process-control  data 

3.  Imposition  of  controls  on   the  process   limits  of  design   documentation 

4.  Japanese  character  and  graphic  output  through   a   non-impact  printer 

5.  Multifaceted  quality  analysis 

6.  Construction  of  a  data   base  for  actual   data   and   standard  times 
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7.  Automatic  collection  of  data 

8.  Capability     for     on-line     instantaneous     utilization     of     the     automated 
output. ^^ 


The  manual  procedures  and  computer-aided  production-control  tools 
introduced  at  the  Kanagawa  Works  and  then  the  Software  Works  between 
1967  and  1976  provided  the  foundation  for  CAPS,  of  which  Hitachi  completed 
an  initial  version  between  1977  and  1930,  by  establishing  a  formal  means  of 
collecting  and  analyzing  both  historical  and  current  data  on  programmer 
productivity  and  project  management.  The  incremental  evolution  of  these 
management  policies  and  tools  is  clearly  evident  in  the  following  chronology 
of  major  milestones   preceding   the   start  of   CAPS   development.    ° 


1967  Completion    of    a    system    for    computing    labor    and    machine    hours    for 

software  development    (Kanagawa  Works) 

1969  Establishment    of    standard    times    for    software    development    (Software 

Works) 

1971  Establishment    of    programmer    ability    coefficients    and    amendments    of 
standard  times 

Completion    of    an    estimation    and    budget    system    using    standard   times 
and   a   simulation    system   for    resource   planning 

Completion     of     a     PERT     Network     System     (PNET),     an     automatic 
diagramming   system  for   schedule  control 

Implementation    of    a    manual    system    for    time-series    analysis    of    test 
processing   and  quality   control 

1972  Completion    of    a    system   for   budget- vs  . -actual   expenditure   control   for 
man-hours   and   machine-hours   for   each    project   and   department 

Implementation   of  a  manual   system  for  document   schedule  control 

1973  Implementation   of   a   manual    system   for  job   process   control 
Implementation     of    a     manual     system    for    productivity    analysis     and 
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control 

1974  Completion    of    a    productivity    analysis    system    for    each    project    and 
department 

1975  Implementation    of    a    manual     system    for    defect    factor    analysis     and 
quality  control 

1976  Development    of    a     time-series     statistical     program     for    forecasting 
defects    (FORCST) 

Establishment  of  a   standard   scheduling   system 

Implementation  of  structured  design   methods 


Central  to  CAPS  was  the  standardization  and  clarification  of  program 
structures;  this  the  factory  accomplished  by  requiring  programmers  to  use 
structured  design  methods.  But  successful  implementation  of  the  computer- 
aided  features  of  the  control  system  depended  equally  on  several 
improvements  in  hardware  technology.  One  was  high-performance  computing 
power,  so  that  numerous  programmers  could  be  on  terminals  connected  to  the 
same  data  bases;  this  was  done  by  installing  Hitachi's  largest  mainframes,  the 
M-180  and  M-200I-I.  CAPS  also  demanded  increased  storage  capacity  for  the 
historical  data  base  recording  past  data  and  present  data,  and  comparing 
these  with  standard  times;  this  came  through  another  Hitachi  product,  MSS 
(Mass  Storage  System).  To  use  MSS  efficiently  required  a  large-scale  data- 
base management  system;  Hitachi  filled  this  gap  with  the  development  of 
several    systems,    most    notably    ADM    (Adaptable    Data    Manager).  Managers 

also  wanted  simple  visual  graphic  output,  to  make  it  easier  to  follow  the 
process  flow;  this  was  achieved  through  the  use  of  non-impact  laser  beam 
printers  that  printed  Japanese  characters  as  well  as  English.  In  addition, 
managers  wanted  to  formalize  the  development  process  for  new  software 
products   and   then   shorten   the  time  needed  for  program  development;    Hitachi 
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has  been  most  successful  in  accomplishing  this  in  the  applications  area,  with 
a  series  of  procedures  and  tools  such  as  EAGLE  and  HIPACE,  as  well  as 
CORAL  (Customer-Oriented  Application  Program  Development  System),  and 
CANDO  (a  prototyping  tool).  These  are  used  primarily  in  Omon  and 
applications   subsidiaries.    ^ 

An  example  of  this  mixing  of  management  policy  and  computer 
technology  can  be  seen  in  the  incorporation  of  standard  times  into  CAPS. 
Controlling  programmer  time  and  machine  time  was  considered  critical 
because,  according  to  Shibata  and  Yokoyama,  these  accounted  for  over  90% 
of  software  production  costs.  Sakata  had  earlier  decided  it  was  necessary  to 
establish  standard-time  estimates  for  man-days  and  computer  time.  Shibata 
and  his  contemporaries,  however,  wanted  to  incorporate  these  into  a 
computerized  system  that  would  enable  Hitachi  to  follow  the  time  estimates 
more  closely  in  the  actual  production  process.  Standard  times  required, 
first,  determining  job  standards  and,  second,  classifying  programmers  by 
ability;  managers  such  as  Shibata  wanted  to  be  comprehensive  but  stressed 
that  standard  times  be  as  simple  as  possible,  so  they  would  be  easy  to  re\ise 
as  well  as  to  simulate,  while  still  covering  most  of  the  appropriate  criteria. 
To  facilitate  the  accuracy  and  utilization  of  the  standard  times,  for  each 
project,  estimates  and  actual  data  were  fed  as  the  project  progressed  into  a 
central  production  data  base  from  on-line  terminals.  This  made  it  possible 
to  compare  progress  to  estimates  and  revise  estimates  during  the  project. 
Under   CAPS   ca ,    1980,    data   points    included  the  following: 

1.  type  of  object  machine    (large,    medium,    small,    peripheral) 

2.  type    of     program     (control     program,     on-line     user    control,     generator, 
simulator,    etc. 
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3.  process   phase   (basic  design,    functional   design,    etc.) 

4.  degree  of  difficulty   (newness) 

5.  production   volume   (number  of  steps) 

6.  language  being   used   (assembler,    COBOL,    FORTRAN,    etc.) 

7.  machine  being  used 

In  addition,  cost  overruns  and  late  deliveries  were  the  result,  Shibata 
and  Yokoyama  believed,  of  inaccurate  daily  scheduling  and  planning.  To 
correct  this  problem,  Hitachi  engineers  wrote  an  algorithm  to  calculate 
manpower  needs  and  schedules  automatically.  This  took  two  factors  into 
consideration:  (1)  actual  working  hours  of  the  committed  programmers;  (2) 
the  minimum  necessary  times  required  for  different  phases  for  each  type  of 
software  program  and  standard  times.  Another  assumption  at  Hitachi  was 
that  there  was  a  relationship  between  the  progress  of  a  software  project  and 
its  quality;  an  ideal  system  would  thus  integrate  production  management  and 
quality  control  data.  Therefore,  they  designed  CAPS  to  estimate 
automatically  the  number  of  defects  likely  for  each  phase  of  development, 
according  to  the  type  of  program,  number  of  steps,  items  tested,  and  other 
factors,    based  on   actual   data.'^^ 

CAPS  relied  completely  on  the  use  of  structured  programming 
techniques,  and  then  used  this  design  technology  to  make  the  structure  of 
programs  visible.  A  data  base  control  system  designed  for  structured 
programs  divided  into  modules,  ADM  (Adaptable  Data  Manager),  automatically 
checked  actual  progress  versus  estimates,  as  each  module  of  a  program  was 
completed.  ADM  then  produced  a  detailed  printout  tracking  the  schedules  for 
design,    testing,    and   inspection,    with   additional    information   on   documentation 
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and  quality  (errors  in  the  specifications,  design  documents,  or  manuals;  bugs 
found  in  test  items  and  coding;  analysis  of  the  causes  of  bugs  and 
countermeasures )  .  Three  subsystems  --  for  documentation  daily-schedule 
control,  testing  preparations  and  programming  progress  control,  and  testing, 
bugging,  and  inspection  progress  control  --  were  also  integrated  within  CAPS 
and  provided  additional  printouts  v\ith  information  and  analysis.  In  this 
sense,  CAPS  was  more  than  just  a  system  for  production  management  that 
provided  a  visual  capability  for  process  monitoring;  it  also  analyzed  data  and 
served   as   a  tool   for  quality  control. 

As  a  production  and  quality  control  system,  CAPS  was  not  fully 
integrated  with  CASD  but  was  developed  in  parallel.  For  example,  CASD 
output  files  were  not  automatically  sent  to  the  CAPS  production  database 
source  file;  nor  did  CASD  automatically  send  corrected  modules  to  CAPS. 
Automating  the  information  flow  was,  however,  a  major  area  of  development 
and  central  to  the  ICAS  program.  '^"^  For  example,  between  19S3  and  19E3, 
Hitachi  completed  links  betvseen  the  two  systems  making  it  possible  to 
register  program  modules  in  the  CAPS  program  library  automatically  from 
CASD,    and   to  automatically  feed  data  on    bugs   from   CASD  to  CAPS. 

Int  eg  rated  Computer-Aided  Software  Engineering  System  (ICAS) 
ICAS  also  represented  a  mixture  of  technology  and  standardized 
methods  and  procedures),  but  was  aimed  at  incorporating  even  more  advanced 
methods  and  computer-aided  tools.  It  contained  four  main  features:  (1)  an 
integrated  methodology  for  the  structuring  and  abstraction  of  software,  using 
a  formal  language  and  graphic  notation,  throughout  a  life  cycle  defined  as 
need     analysis,      requirement     definition,     planning,     programming,     testing. 
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operation  and  maintenance;  (2)  interactive  tools  for  each  phase  of  the  life- 
cycle;  (3)  an  "intelligent"  workbench,  using  a  personal  computer,  allowing 
programmers  to  use  the  tools  by  having  dialogues  with  the  computers;  and 
(4)  complete  management  of  information  for  all  phases  using  a  relational 
database.  The  basic  philosophy  of  this  approach  was  to  develop  not 
"methodology-free"  tools,  leaving  it  up  to  the  user  to  decide  on  which 
development  methodology  to  employ,  but  to  present  computer-aided  tools 
with  a  "fixed  development  methodology  of  multi-purpose  use,"  allowing  users 
to  develop  software  quickly  by  using  the  tools  "without  having  to  worry 
about  which   methodology  to  apply." 

Requirements  definition  involved  stepwise  refinement  in  the  procedural, 
functional,  and  logical  description  of  the  system  being  designed.  From  the 
conceptual  model,  programmers  determined  the  control  structure,  abstracted 
data  and  formed  data  modules,  and  defined  functional  algorithms  with  only 
three  control  elements  --  sequence,  repetition,  and  selection  --  using  PDL  or 
PAD  (Problem  Analysis  Diagrams).  ICAS  then  automatically  converted  the 
functional  algorithm  into  statements  written  in  a  programming  language. 
Several  tools  simplified  needs  analysis  and  description  ( PPDS--Planning 
Procedure  to  Develop  Systems  and  FRAME--FormaIized  Requirements  Analysis 
Method),  and  requirements  definition  (RDL/RD  (Requirement  Definition 
Language/Analyzer) . 

Design-aid  tools  included  ADDS  (Automated  Design  and  Documentation 
System)  and  MDL  (Module  Design  Language),  already  part  of  CASD,  as  well 
as  PDL/PAD  (Problem  Design  Language/Problem  Analysis  Diagram).  PDL/PAD 
was  intended  to  automate  coding  and  completely  integrate  design 
documentation    and    source   programs.       it   consisted   of   a    program    logic   design 
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tool,  based  on  structured  programming,  and  a  tool  to  convert  automatically 
design  documents  into  high-level  language  source  programs  (PL/1),  or  vice- 
versa.  For  example,  departments  writing  in  COBOL  were  able  to  automate  as 
much     as     30V    of     coding     tasks      '^  In     addition,     DBDS     (Database     Design 

System)  was  a  tool  for  designing  databases  Test-aid  tools  included  AGEKT, 
TESCO,  and  CEG,  discussed  above.  A  Software  Engineering  Workbench 
(SEWB)  and  a  Softvsare  Engineering  Database  (SEDB)  provided  an 
infrastructure  to  use  these  tools  in  an  integrated  manner.  The  relational 
database   stored   all   data   from   each   tool    input    into   the   computer.'^'' 

The  quality  control  portions  of  ICAS  we'-e  in  actual  operation  in  the 
Software  Works  as  of  1986  as  part  of  CASD.  Other  subsystems  of  ICAS 
being  refined  at  the  Systems  Development  Laboratory,  Hitachi  Software 
Works,  and  Omori  Software  Works  were  already  in  use  for  applications 
software.  Most  important  were  HIFACE,  the  set  of  procedures  and 
methodologies  to  guide  system  design,  and  EAGLE  (Effective  Approach  to 
Achieving  High  Level  Software  Productivity),  an  automated  system- 
development  support  tool  used  to  locate  reusable  modules  from  a  parts 
library. '^°  EAGLE  was  also  linked  to  the  PAD  system,  making  it  possible 
to  generate  nev\  modules  from  high-level  designs  while  retrieving  exisitng 
modules   for  other  functions   from  a   parts   database.'*^' 

Even  before  complete  integration  within  the  ICAS  project,  HIPACE 
provided  a  factory-type  methodological  infrastructure  and  EAGLE  a  factory- 
type  technological  interface  for  applications  development  at  Hitachi's  Omori 
facility  and  Hitachi  Software  Engineering .  ''■°  Hitachi  intended  HIPACE  to 
reduce  costs  in  customized  applications  development  by  facilitating 
communication     between    the    company's     system    engineers     and    customers    and 
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applying  well-defined,  standardized  procedures  to  system  development  and 
project  management.  It  set  the  process  flow  as  follows:  analysis,  system 
planning,  system  design,  program  design,  program  construction,  test,  transfer 
(to  customer),  installation  and  evaluation.  First,  engineers  used  Structured 
Data  Flow  diagrams  (SDF)  to  analyze  customer  needs.  Planning  Procedure  to 
Develop  System  (PPDS)  and  Standard  Procedure  to  Develop  Systems  (SPDS) 
then  provided  documentation  and  project-management  standards  for  each 
phase  of  the  development  process.  A  set  of  worksheets  referred  to  as  Work 
Breakdown  Structure  (WBS)  provided  the  format  for  planning  of  the  actual 
design,  programming,  and  testing  tasks.  To  facilitate  long-term  maintenance 
and  reliability  (and  reusability),  engineers  then  used  HIPACE-SA  for 
structured  analysis,  HIPACE-SD  for  structured  design,  and  HIPACE-SP  for 
structured   programming    (usually   in   COBOL  or   PL/1).^^ 

The  EAGLE  system  extended  the  HIPACE  methodology  by  adding  four 
computer-aided  functions:  (1)  conversational  language  processing  from  system 
design  through  testing,  using  easily  understandable  menus;  (2)  a  central 
database  on  design  specifications  and  program  implementation,  as  well  as 
project  management  (tracking  information  from  the  standardized  work  sheets 
defined  in  the  SPDS  manual)  to  facilitate  system  development  and 
maintenance;  (3)  automated  construction  of  new  source  programs  from 
standardized  patterns  ("skeletons")  and  components  (sub-routines);  and  (4) 
automatic  compilation  of  maintenance  documentation. 

The  process  flow  in  using  EAGLE  was  also  clearly  defined.  The  first 
two  steps  are  the  analysis  of  data  types  and  interrelationships  and  their 
recording  in  a  "data  dictionary"  database;  this  is  followed  by  registration  of 
the    system    design    and    program    documentation    in    a    specifications    database. 
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At  this  point,  nevs  standardized  modules  are  identified  and  registered  in  a 
central  program  parts  library,  and  existing  components  are  identified  for  the 
system  being  developed,  if  applicable.  This  makes  it  possible  to  "assemble" 
programs  using  the  new  and  reused  modules.  Hitachi  also  makes  these 
standardized  modules  available  as  products  with  the  EAGLE  systems  it  sells 
to  customers,  although  company  engineers  have  found  that  "data  modules" 
are  easier  to  use  than  processing  algorithms,  which  tend  to  be  more  difficult 
to  standardize.  EAGLE  next  generates  an  outline  of  the  program  from  the 
detailed  (module-level)  specifications  and  then  produces  a  source  program. 
The  source  program  is  then  edited  to  add  particular  functions  wanted  by 
individual  users.  Finally,  test  commands  are  automatically  generated  and 
carried  out    in   conversational    language   (Japanese) .  ^ '^ 

Recent  efforts  (1984-1986)  to  develop  the  EAGLE  system  have  focused 
on  making  it  both  more  flexible  for  meeting  customer  needs  as  well  as  more 
appropriate  to  a  factory  environment  stressing  division  of  labor  and  maximal 
use  of  standardized  components.  One  the  one  hand,  the  conversational 
interface  has  been  improved;  and  the  system  now  handles  PL/1  and  CORAL 
(Customer-Oriented  Application  Program  Development  System  --  a  Hitachi 
language  for  writing  specifications  in  Japanese),  in  addition  to  COBOL.  N'ew 
software  makes  it  possible  for  customers  to  design  their  own  menus,  rather 
than  use  only  the  ones  Hitachi  provides,  to  add  unique  features  to  programs 
being  constructed.  The  system  also  can  now  be  used  to  construct  data-base 
and  data-communications  programs,  in  addition  to  business-applications 
programs . 

EAGLE  has  also  been  modified  to  work  more  smoothly  in  a  time-sharing 
environment,     to     allow     more    people    to    divide     up    the    tasks    of     system 
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development  and  have  better  access  to  the  library  of  reusable  components.  '  ^ 
The  overall  result,  according  to  Hitachi  data,  is  that  programs  designed  with 
EAGLE  generally  show  a  2.2-fold  improvement  in  "productivity"  (Hitachi 
usually  measures  this  by  lines  of  code  per  programmer  in  a  given  time 
period).  As  indicated  in  the  table  below,  EAGLE  also  has  shifted  more 
effort  into  system  design  and  substantially  reduced  necessary  for  testing. 
For  a  hypothetical  program  taking  a  year  to  develop  without  EAGLE,  this 
would  mean  a  reduction  in  development  time  to  5.4  months,  with  testing 
being  reduced  from  4.8  to  1.4  months  and  program  implementation  from  4.8 
to  1.9  months.  Around  1986-1987,  the  Omori  Works  also  introduced  a  design 
automation  system  using  artificial  intelligence  techniques  to  automate  some 
of  the  system  engineering  tasks,  such  as  documentation  construction,  data 
retrieval   for   hardware  and   software  configurations,    and   system   simulation .' ^■^ 

Without  EAGLE  With   EAGLE"*^^ 

Development  100      (12  months)  45   (5.4  months) 

System 

Design  20%     (2.4)  38%   (2.1) 

Program 

Implementation         40%     (4.8)  36%   (1.9) 

Test  40%     (4.8)  26%   (1.4) 

Another  system  to  save  on  design  time  is  APP  (Applicable  Program 
Products),  which  is  a  library  of  basic  programs  for  different  applications 
that,  if  appropriate  for  a  particular  customer,  Hitachi  will  use  as  a  basis  for 
building  semi-customized  systems.  The  objective  of  this  approach  was  to  cut 
costs     in    development,     shorten    the    time    required,     and    guarantee    at    least 
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"stable  quality  in  operations."  As  of  1957,  APP  core  programs  existed  for 
banks  (on-line  banking,  credit  evaluation,  customer  information); 
broadcasters;  hospitals  (accounting);  local  governments  (residents  information 
systems,  library  information  systems);  finance  (accounting  systems);  personnel 
management  and  payroll  calculation;  videotex;  computer- room  operations  and 
control.''^'' 


V.    ADDITIONA L  ORGANIZATIONAL   FLEXIBILITY 

Where  Hitachi  has  needed  more  organizational  or  geographic  diversity 
to  meet  customer  needs  than  its  two  software  factories  provided,  it  has 
relied  on  approximately  23  subsidiaries.  The  largest  were  Nippon  Business 
Consultants  (ca.  2500  employees),  established  in  1959;  Hitachi  Software 
Engineering  (ca.  2400  employees),  established  in  1969;  and  Hitachi  Micro- 
Computer  Engineering  (ca.  1500  employees),  established  in  1982  ^  Hitachi 
classified   these  firms    into  ten   groups,    with    several   overlapping: 

(1)  General   systems   and   applications    software   houses 

(Nippon  Business  Consultants,  Hitachi  Software  Engineering,  Hitachi 
Information  Networks,  Hitachi  Computer  Consultants,  H/tachi 
Computer  Engineering;  and  the  regional  companies  Hitachi  Chugoku 
Software,  Hitachi  Tohoku  Software,  Hitachi  Chubu  Software,  Hitachi 
Nishibu    Software) 

(2)  Industrial-use  control   systems 

(Hitachi  Industrial  Engineering,  Hitachi  Process  Computer 
Engineering,    Hitachi    Control    Systems) 

(3)  Semiconductor   and   micro-computer    software 

(Hitachi   VLSI    Engineering,    Hitachi   Micro-Computer   Engineering) 

(4)  Information-processing    and   telecommunications    systems 

(Hitachi    Electronic   Service,    Hitachi    Communications) 

(5)  Video   and   audio  equipment,    and   personal-computer   systems    and   software 

(Hitachi  Video) 
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(6)  Semiconductors   and  electronic  devices 

(Hitachi   Electronic  Devices) 

(7)  Precision   instruments   software 

(Hitachi    Instruments   Engineering) 

(8)  Automotive  electronics 

(Hitachi   Automotive   Engineering) 

(9)  Robotics,    control   equipment,    and   business   personal   computers 

(Hitachi    Kyoba   Engineering) 

(10)  Personal   Computers 

(Hitachi  Micro-Software  Systems) 

In  addition,  other  Hitachi  factories  produced  specialized  software 
products.  Most  prominent  was  the  Omika  Works,  a  factory  producing  control 
computers  and  terminals  in  Hitachi's  power  generation  and  transmission  group 
that  had  another  thousand  programmers  writing  real-time  industrial  control 
software.  Omika  also  used  the  versions  of  CAPS  and  ICAS,  although  these 
had  to  be  modified  for  the  different  architecture  of  the  control  computers. 
There  were  also  several  hundred  programmers  at  the  Totsuka  Works  writing 
switching  systems  software,  and  at  the  Kanagawa  Works,  writing  design 
automation  software  for  computer  hardware.  Both  Totsuka  and  Kanagawa 
used  the  CAPS   and   CASD  tools. ""^^ 

A  brief  discussion  of  Hitachi  Software  Engineering  illustrates  how  the 
Hitachi  group  has  managed  to  combine  flexibility  in  serving  customer  needs 
with  a  disciplined  engineering  and  manufacturing  approach  to  software 
development.  Some  sections  of  this  subsidiary  of  some  2500  employees 
worked  as  part  of  the  permanent  workforce  in  Hitachi's  in-house  software 
factories,  while  other  groups  did  customized  systems  development  for  a  wide 
variety  of  Japanese  customers. 
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The  company  was  organized  around  design  departments  specialized  in 
specific  industries  or  applications,  link  financial  systems  or  hospital  systems. 
Unlike  the  Omori  Works,  there  were  no  separate  implementation  departments; 
the  design  departments  did  their  ovs  n  detailed  design  and  coding,  although 
sections  specializing  in  implementation  as  opposed  to  systems  engineering  did 
exist  in  each  department.  Program  libraries  and  reusable  parts  databases 
were  also  developed  for  specific  industries  or  applications,  corresponding  to 
the   departmental   organization    structure. 

There  was  a  functional  division  of  labor  with  the  customers,  including 
the  Hitachi  software  factories;  this  depended  on  how  much  expertise  the 
customer  had,  relative  to  Hitachi  Software  Engineering.  In  some  cases, 
where  the  customer  has  a  lot  of  expertise,  Hitachi  Software  Engineering 
would  receive  only  functional  specifications  and  then  do  the  detailed  design 
and  program  construction.  This  was  done  on  occasion  with  the  Omori 
Works,  which  had  considerable  expertise  in  system  engineering;  Hitachi 
Software  Engineering  would  then  serve  as  the  "factory"  to  construct  and  test 
the  actual   program. 

In  the  view  of  Matsumoto  Yoshiharu,  manager  of  Hitachi  Softv\are 
Engineering's  RlD  department,  and  Matsuzaki  Yoshizo,  an  applications 
software  manager,  it  was  not  necessarily  the  division  of  labor  which 
distinguished  a  "factory  approach"  from  a  non-factory  approach.  Their 
philosophy,  and  that  of  managers  such  as  Shibata  Kanji  and  Nokoyama  Yoichi 
in  Hitachi  Software  Works,  was  that  the  degree  of  control  over  processes, 
quality,  and  costs  determined  whether  a  product  was  made  in  a  factory-like 
organization  or  not.  In  particular,  Hitachi  managers  emphasized  their  design 
review   procedures    along    with    extensive    (and   expensive)    bug   analyses 
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basic  strategy  used  to  eliminate  bugs  consisted  of  three  elements:  (1) 
careful  design  reviews  beginning  with  functional  specification  and  detailed 
design  phases  to  catch  bugs  early  in  development;  (2)  elimination  of  boring 
tasks  such  as  coding,  through  automatic  code  generation  from  PAD  diagrams 
or  from  reusable  software  modules;  and  (3)  use  of  the  FORCAST  program  to 
predict  bug  levels  and  then  to  test  until  the  predicted  numbers  of  defects 
are  found.      ' 

When  Hitachi  Software  Engineering  served  as  a  manpower  souce  for 
Hitachi  Software  Works  or  Omori  Software  Works,  its  employees  followed  the 
factory  practices  and  used  the  tools  at  these  facilities.  In  other  cases,  they 
still  usually  applied  tools  and  methods  transferred  from  Hitachi  such  as 
CASD,  CAPS,  and  HIPACE,  but  with  several  in-house  systems.  Hitachi 
Software  Engineering  was  also  remarkably  efficient  in  project  control.  The 
company  reported  in  1981  that  it  was  able  to  complete  98%  of  projects  on 
time  and  99%  at  an  actual  cost  between  90%  and  110%  of  the  original 
estimates.  This  compared  to  300%-overruns  during  the  early  1970s.  (The 
average  project  size  was  50,000  lines  of  code;  the  largest  were  about  500,000 
lines.) '^°  Control  was  exercised  through  separate  databases  for  manpower, 
bugs,  and  project  management;  these  were  not  yet  linked  in  1987,  though 
this  was  in  the  planning  stage.  As  in  Hitachi  Software  Works,  some  of  the 
data   input  procedures   were  automated,    and  others   manual.''^ 

As  did  the  Hitachi  factories,  Hitachi  Software  Engineering  emphasized 
extensive  programmer  training  (1-year  training  periods,  including  2  months  of 
off-the-job  training  when  they  entered  the  company),  as  well  as  strict 
implementation  of  top-down,  structured  design  and  careful  controls  on 
budgets    and    project    management,    including    standard    times    for    programmers 
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(design  and  coding).  Historically,  managers  at  the  subsidiary  focused  first  on 
setting  up  a  project  and  production  auditing  system  (1969-1975);  applying 
structured  programming  techniques  and  software  tools  (1976-1978); 
productivity  improvement  and  quality  assurance  through  the  standardization 
of  methodologies  and  tools  (1979-1981);  and  productivity  and  quality 
improvement  through  the  generation  of  reusable  modules  ("standard 
patterns"),  their  cataloging  in  program  libraries  specialized  for  different 
applications,    and   utilization    in   the   writing   of   new    programs.    ^^ 

In  addition  to  program  libraries,  Hitachi  Software  Engineering  also 
relied  on  a  separate  library  for  "common  parts"  that  served  as  reusable 
modules.  These  included  patterns  for  mainframe  operating  systems  and 
related  programs,  as  well  as  for  functions  such  as  message  reception, 
message  format  and  contents  checking,  data-base  management  system 
processing,  message  editing  and  switching,  screen  mapping,  line-overflow, 
error  displays,  program-function  key  code  analysis,  screen  editing,  and  table 
"look-up."  Some  managers  assigned  programmers  exercises  on  a  monthly 
basis  to  make  them  familiar  with  subroutines  stored  in  the  program 
libraries.  A    Production    Engineering    Center  was    responsible   for   screening 

new  modules  recommended  by  project  managers  for  registration  in  the  parts 
library.  The  company  also  gave  out  rewards  to  programmers  who  registered 
particularly  useful  modules,  based  on  an  analysis  of  the  specifications  (not 
actual  reuse  rates).  In  general,  all  programmers  were  encouraged  to  look 
into  the  reuse  library  at  the  design  stage  (between  functional  specifications 
and  detailed  design),  to  determine  if  there  may  be  parts  they  could  reuse. 
Through  these  policies,  as  well  as  the  use  of  tools  such  as  EAGLE,  Hitachi 
Software    Engineering    was    able    to    increase    reuse    rates    from    a    level    of    10   to 
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20%     in     the     early     1980s     to     about     40%     in     1987,      depending     on     the 
department.    ^■^ 

Since  the  activites  of  Hitachi  Software  Engineering  spread  across 
numerous  areas  and  customers,  it  did  not  have  a  centralized  company  data 
base   for    production    control.       Standards    were   also   frequently   determined    by 

customers,     since    the    company    was    dedicated    to    producing    customized 

1  9T 
programs.  Nonetheless,     an     integral    and    clearly    stated    component    of 

management    strategy    was    rigid    discipline   throughout   the   firm.       In    fact,    the 

two   managers    who    spearheaded    the   development   of    production    technology    at 

this     subsidiary,     after    moving    over    from    Hitachi     Software    Works,     openly 

admitted    to    the    use    of    extensive    training    techniques    to    make    programmers 

comply  with   company   standards   for   program   design:    "To  meet  our  production 

criteria,     project     procedures     have     been     standardized     and     imposed    on 

employees.         If    any    modules    deviate    from    the    coding    standard,     they    are 

returned  to  the  production    line."'^- 


CONCLUSION 

Hitachi  did  not  impose  standardized  practices  or  emphasize  reusability 
as  much  as  some  other  firms  because  of  the  broadness  of  its  product  lines 
and  the  diversity  of  its  customers,  even  within  single  facilities.  Yet  it  is 
significant  as  the  first  company  to  introduce  successfully  a  factory  strategy 
and  structure  to  manage  the  process  of  large-scale  software  development. 
Much  can  be  learned  about  the  patience  required  to  rationalize  management 
of  a  new  and  complex  product  and  process  technology  from  Hitachi's 
experience. 
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Intervievss  v.ith  managers  and  a  study  of  technical  and  historical 
documentation  indicate  that  Hitachi  s  movement  tov>ard  the  factory  model 
resulted   from   three   interrelated   strategies: 

1)  A  company  policy  of  establishing  independent  factories  (which  included 
both  product  engineering  and  mass-production  functions)  for  each  major 
product  area. 

2)  Belief  on  the  part  of  managers  responsible  for  corporate-  and  division- 
level  strategy,  as  well  as  for  software  development,  that  a  centralized 
and  disciplined  factory  environment,  integrating  product  engineering  and 
mass-production  activities,  offered  for  any  product  the  potential  of 
improving  worker  productivity  and  quality,  as  well  as  project  and  cost 
control . 

3)  Top  management  decision  and  commitment  (including  di\'isional 
executives  and,  especially,  the  company  president)  to  treat  software  as 
a  product  whose  development  could  and  should  be  controlled  in  a 
factory,  as  any  other  product  the  company  manufactured  --  making  it 
necessary  to  apply  company- wide ,  standardized  accounting  and 
management   controls   to   all    software   engineering   activities. 

The  history  of  Hitachi  Software  Works  also  indicates  that  the 
foundations  of  the  factory  were  primarily  policy-oriented.  Somewhere  in 
between  technology  and  policy  was  the  introduction  of  a  structured 
programming  technique  during  the  mid-1970s.  Structured  programming  is 
really  a  methodological  tool;  since  it  was  necessary  to  train  and  require 
programmers  to  use  this  as  standard  procedure,  the  use  of  this  new 
technology   or   tool    involved   critical    policy    decisions    and    implementation.    This 
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was  especially  important  because  structured  programming  as  defined  by 
Hitachi  became  the  foundation  of  the  factory's  standard-times,  cost- 
accounting,  and  general  production-control  systems,  as  well  as  specific 
support  tools.  The  rather  sophisticated  (computer-aided)  technological 
infrastructure  evolved  after  the  basic  policy  infrastructure,  but  rapidly,  from 
a  few  tools  at  first  to  an  extensive  set  of  interrelated  systems  that  are 
increasingly   being   further   integrated. 

A  contrast  between  implementation  of  the  factory  model  at  Hitachi  and 
the  experiment  at  System  Development  Corporation  in  the  mid-1970s  also 
offers  some  suggestions  regarding  why  one  company  might  succeed  better 
than  another  at  this  approach.  SDC  attempted  to  introduce  simultaneously  a 
factory  system  containing  both  a  technological  infrastructure  and  a  policy 
infrastructure  (set  of  standard  procedures  covering  system-analysis,  design, 
implementation,  testing,  and  project-management).  While  the  technology 
(central  production  database,  program  library,  automated  documentation  and 
testing  tools,  etc.)  was  there,  programmers  seemed  to  dislike  the 
standardized  environment  and  reusing  other  programmers'  code.  Perhaps 
more  important  was  that  project  managers  disliked  giving  up  control  to  the 
factory  and  work  for  the  facility  dwindled;  this  led  eventually  to  the 
dismantling    of    the    factory    infrastructure    through    the    dispersal    of    systems 

engineers    to    different    sites    to    develop    programs,     with     little    capability    to 

1  9S 
divide    labor   or    reuse   modules    as    once   envisioned    in    the   factory   concept.  '^"^ 

Hitachi,  on  the  other  hand,  incrementaly  developed  and  imposed  a 
policy  infrastructure  over  a  period  of  several  years,  thereby  training 
programmers  and  managers  to  operate  within  a  highly  standardized,  factory- 
like environment.      Hitachi   modified  these  procedures   gradually   and  then   from 
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the  mi-1970s  began  investing  heavily  in  tools  and  large-scale  computer-aided 
systems  --  the  factory-type  technological  infrastructure.  This  shift  in  focus 
to  technology-based  tools  and  automation  thus  came  after  successfully 
innovating  in  process  management  by  applying  a  standardized  approach  to 
both    system   and   applications    softvsare   development. 

One  might  also  identify  a  parallel  here  with  Toyota,  a  company  often 
cited  for  its  excellence  in  production  management.  The  largest  Japanese 
automaker  has  consistently  demonstrated  the  world  s  highest  levels  of 
physical  productivity  in  automobile  manufacturing  by  deemphasizing  the  use 
of  sophisticated  automation  or  computer-based  systems,  preferring  instead  to 
focus  on  process  control  and  innovation,  as  well  as  flexible  tools,  to  extend 
the  performance  of  human  workers.  Only  after  these  policy  innovations  have 
Toyota  managers  agreed  to  introduce  more  automation,  but  only  if  the 
technology  is  sufficiently  flexible  (such  as  programmable  robots)  to  fit  into 
its  manufacturing   system  and   supplement   the  efforts   of   human   workers. 

The  comparison  with  Toyota,  as  well  as  the  SDC  case,  reinforces  the 
notion  that  technological  advances  alone  do  not  necessarily  bring  as  many 
benefits  in  productivity  as  simply  better  process  management.  The  Hitachi 
case  in  software  suggests  that,  with  the  proper  mixture  of  policy  and 
technology,  including  a  strategy  to  assure  the  compliance  of  managers  and 
engineers  or  other  programmers,  the  factory  approach  should  offer  several 
advantages  in  efficiency.  As  suggested  in  the  first  paper  from  this  research 
project,    these  might   include  the  following: 


Institutionalization     or     dissemination     of     "good"     technologies     and 
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programming  or  manaqefnent  practices. 

The  production  engineering  departments  in  Hitachi's  software  factories, 
as  well  as  the  factory  training  programs,  were  responsible  for  introducing 
techniques  and  tools  that,  in  textbooks  on  software  programming  and 
engineering  management,  are  widely  considered  to  be  fundamentally  good 
practices.  These  include  structured  design  methods;  bug-forecasting  data 
collection  and  models;  documentation  standardization  and  control  systems; 
formal  project-management  and  design-review  systems;  program  libraries; 
wide  use  of  computer-aided  design,  coding,  and  testing  tools;  and  promotion 
of  standardization  of  practices  and   reusability  of  code  where  possible. 


Providing  a   sufficient  scale  of  people  and  operations   to  justify   research 
and  development  for  improving  process  technology  and  techniques. 

In  addition  to  engineering  departments  in  the  software  factories, 
Hitachi  also  used  the  System  Development  Laboratory  to  perform  R%D 
activities  related  to  programming  support  tools  and  methods.  The 
centralization  of  software  production  at  the  Software  Works  and  Omori 
provided  an  in-house  core  of  3000  programmers  and  supporting  staff;  Hitachi 
Software  Engineering  and   Nippon   Business   Consultant  added  another  5000. 

Improving    process    efficiency    through    teamwork    and    better    inter-qroup 
communication. 
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This  can  be  seen  in  two  examples.  One,  is  that  the  percentage  of  late 
projects  in  the  Software  Works  dropped  dramatically  within  a  fevs  years  of 
the  founding  of  the  factory,  from  over  72%  in  1970  to  13%  in  1973  and  to  a 
remarkably  low  7%  in  1974  and  1979,  with  an  average  of  12%  during  1974- 
1985.  The  figure  for  19S6  was  about  5%.  These  numbers  placed  Hitachi 
Software  VNorks  along  with  other  firms  leading  in  this  category.  Variations 
in  these  figures  reflect  the  level  of  activity  within  the  factory,  with  more 
late  projects  when  Hitachi  was  completing  new  large  new  projects  --  for 
example,  a  new  mainframe  operating  system.  But,  in  general,  reporting 
procedures,  as  well  as  CAPS  (Computer- Aided  Production  Control  System  for 
Software),  made  it  possible  to  integrate  manpower-control,  process-control, 
and  quality-control  functions  and  support  tools.  Another  example  of  the 
factory  benefits  is  Hitachi's  overturning  of  Brook's  law  about  more 
programmers  added  to  a  late  project  causing  projects  to  be  later.  The 
factory  environment  allowed  Hitachi  managers  to  add  people  (albeit  the  best 
people   available   and   not   just   anyone)    to   help   finish    projects   on   time. 
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HITACHI   SOFTWARE  WORKS:    PERFORMANCE  DATA 


Year 

Workers 

Sales/Worker 

Projects  Late 

Reported  Buqs 

1969 

348 

lOO(lndex) 

--  % 

N.A. 

1970 

675 

202 

72.4 

N.A. 

1971 

926 

178 

56.6 

N.A. 

1972 

1107 

190 

36.3 

N.A. 

1973 

1169 

204 

13.0 

N.A. 

1974 

1079 

331 

6.9 

N.A. 

1975 

1093 

313 

9.8 

N.A. 

1976 

1141 

360 

16,8 

N.A. 

1977 

1288 

386 

16,1 

N.A. 

1978 

1395 

468 

9.8 

lOO(lndex) 

1979 

1398 

505 

7.4 

79 

1980 

1398 

594 

10.7 

48 

1981 

1419 

678 

14,0 

30 

1982 

1437 

792 

12,9 

19 

1983 

1666 

943 

18.8 

13 

1984 

1833 

1257 

16.3 

13 

1985 

2018 

N.A. 

18.0 

14 

Source:  Based  on  data  provided  by  Shibata  Kanji,  Manager,  Engineering 
Dept.,    Hitachi    Software  Works,    23  July   1986. 

Notes:  Sales  per  worker  reflects  the  value  of  software  products  sold  by 
Hitachi  Software  Works  to  other  Hitachi  profit  centers  as  well  as  to  outside 
customers.  Outside  sales  represented  approximately  90%  of  revenues;  in- 
house  customers  were  charged  prices  below  market  rates.  Reported  Bugs 
refers   to  major   bugs    reported   by  outside  customers   per  machine  per  month. 
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O rg anization al    focus    on     ra isinq    enq m eerinq    prod u c t ivitv    and    product 
quality   (defect  control) . 

As  indicated  in  the  table,  sales  productivity  of  Hitachi  employees  in  the 
Software  Works  doubled  within  one  year  of  the  factory's  opening  and  has 
increased  significantly  overtime,  although  direct  productivity  figures  for  the 
facility  are  proprietary.  Company-wide  and  factory  programs,  such  as  the 
Management  Improvement  movement  and  system  gleaning  practice,  form.ally 
promoted  the  analysis  and  implementation  of  measures  to  improve  labor 
performance  and  product  quality.  The  central  production  data  base  for  the 
factory  started  in  the  mid-1960s  also  made  it  possible  to  track  programmer 
productivity  as  well  as  defect  measures,  and  thereby  have  precise  data  tc  use 
in  determining  specific  methods  or  in  developing  new  tools  to  be  used 
throughout  the  factory.  Perhaps  most  important,  the  administrative  and 
technological  infrastructures  of  the  factory  --  manpower,  process,  quality, 
and  product  control  in  the  area  of  production  management;  standardization, 
design,  and  inspection  in  the  area  of  product  engineering  --  facilitate 
performance  analysis  and  improvement.  Individuals  do  not  ha\e  to  expend 
time  and  energy,  for  example,  in  deciding  which  languages  or  methods  to 
use,  or  whether  to  develop  a  particular  support  tool.  Systems  such  as  EAGLE 
also  save  extensive  manpower  by  automating  much  of  testing  and  by 
recycling   program   components. 

In  quality,  Hitachi  employs  a  measure  of  user- reported  major  bugs  and 
has  reduced  bugs  from  an  index  of  100  in  1978  to  14  in  1985.  One  unofficial 
estimate  is  that  this  figure  represented  approximately  0.01  defects  per 
program   package   per   machine    installation    per   year,    and   placed   Hitachi    in   the 
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low  category,  along  with  other  leaders  in  this  measure  that  participated  in 
the  survey.  ■^'  According  to  Shibata,  the  decrease  in  bugs  reflected  several 
factors:  a  new  System  Simulation  Tester  (SST)  completed  in  1977-1979;  CASD 
(Computer-Aided  Software  Development  System),  another  group-programming 
tool  to  facilitate  product  standardization,  design  support,  and  inspection 
functions;  reused  code,  reaching  approximately  90%  in  new  releases  of 
products  such  as  operating  systems;  and  increasing  sales  of  essentially  bug- 
free  programs.  '^° 


Reducing    waste    and     redundancies    due    to    dysfunctional    behavior    of 
individuals  and  the  lack  of  an  organizational   strategy. 

High-level  factory  managers  such  as  Sakata,  as  well  as  middle  managers 
from  the  engineering  department  such  as  Shibata,  have  set  a  clear  direction 
for  personnel  and  technological  development  in  the  Software  Works.  Their 
initial  focus  has  been  on  gathering  information  on  software  technology  and 
then  standardizing  methods  and  tools,  and  setting  factory-level  performance 
goals.  Later  efforts  have  focused  on  automation  and  reusability.  The 
factory  infrastructure  and  strategy  they  have  created  has  reduced  the 
possibility  of  individuals  duplicating  the  efforts  of  others  in  tool  or  method 
development,  as  well  as  writing  code,  and  lessened  the  likelihood  of  workers 
engaging  in  practices  that  are  contrary  to  the  organizational  goals  such  as 
to  develop  reusable  modules,  or  use  factory-wide  tools  and  standardized 
methods   that  facilitate   reusability,    maintenance,    testability,    and   the   like. 
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Maintenance  of  o rganizat ional  and  technical   "flexibility." 

Both  the  technological  and  policy  infrastructures  of  the  Hitachi 
softvtare  factories  have  been  evolving  since  1969.  Most  of  the  tools 
developed  for  Hitachi  Software  Works  (and  then  introduced  in  other  Hitachi 
facilities  or  subsidiaries),  such  as  CAPS,  CASD,  HIPACE,  and  EAGLE,  ha\e 
been  adaptable  enough  to  incorporate  important  technical  advances,  such  as 
additional  linkages  between  systems,  the  addition  of  other  support  tools  for 
documentation,  testing,  and  the  like,  or  increased  capabilities  of  adapting  to 
non-standardized  customer  needs.  Structured  design  has  also  endured  for 
well  over  a  decade.  High  levels  of  reusability  indicate  as  well  that  Hitachi 
programmers  find  modules  in  the  program  library  are  not  obsolete.  While 
the  factory  approach  might  seem  to  make  it  difficult  for  a  particular  facility 
to  respond  to  a  unique  customer  need  or  a  specific  type  of  technology, 
Hitachi  has  been  addressing  these  concerns  through  continued  development  of 
cu  stome  r  -  or  ien  ted  design  systems  such  as  EAGLE,  as  well  as  the 
establishment  of  numerous  subsidiaries  and  new  factory  departments  such  as 
for   artificial    intelligence. 
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